Permalink
Comparing changes
Choose two branches to see what’s changed or to start a new pull request.
If you need to, you can also or
learn more about diff comparisons.
Open a pull request
Create a new pull request by comparing changes across two branches. If you need to, you can also .
Learn more about diff comparisons here.
...
- 16 commits
- 168 files changed
- 5 contributors
Commits on Apr 2, 2025
-
Mill 0.13 Compat: Add
JvmWorkerApi,JvmWorkerUtiland `JvmWorkerM……odule` (#4838) Allows users to replace the deprecated APIs: `ZincWorkerApi`, `ZincWorkerUtil` and `ZincWorkerModule` by their new names `JvmWorkerApi`, `JvmWorkerUtil` and `JvmWorkerModule`. Replaced some usage of this deprecated API in the codebase, to reduce warnings. Tracker: #4716 Pu 8000 ll request: #4838
-
-
Mill 0.13 Compat: Add `Module.{moduleDir,moduleInternal,moduleSegment…
Commits on Apr 4, 2025
-
Backport "Fix wildcard and type selector query bugs" (#4862)
Backports #4861 Fixes #4536 and #4514 and #3618 - `__` was incorrectly adding the current module to `seenModules`, which causes problems when it recurses on the current module. This PR skips updating `seenModules` when recursing on the current module. There are probably other edge cases we haven't noticed in this cycling module graph detection logic, but for now this just fixes the reported issue and the test suite should give confidence we didn't regress anything - `typePatterns` was incorrectly being resolved only on modules during the `__` wildcard resolution, and allowing tasks to pass through without filtering. This PR moves the filtering to after `resolveDirectChildren`/`resolveTransitiveChildren` has completed, ensuring we filter out unwanted tasks as well. Added unit tests for these cases
-
Avoid spurious deprecation message when using non-deprecated API (#4860)
Fix an deprecation message the user can't get rid of, reported via Discord. ``` build.sc:27:32: class JarManifest in package api is deprecated (since Mill 0.12.10): Use mill.uitl.JarManifest instead override def manifest = Task { ``` Also fixed some deprecation in the build. Pull request: #4860
Commits on Apr 8, 2025
-
Backport JS and Python lib improvements from main to 0.12.x (#4893)
Largely just `git checkout main -- pythonlib javascriptlib example/pythonlib example/javascriptlib` and then cleaned up the compile errors
Commits on Apr 11, 2025
Commits on Apr 12, 2025
-
Backport "Add ability to define
PackageExternalModules that can be ……called via just `pkg.path/` rather than `pkg.path.ObjectName/`" (#4920) Backport of #4918 This simplifies a common case where there is only one `ExternalModule` in a package, e.g. 1. `./mill mill.scalalib.scalafmt.ScalafmtModule/` can now be called via `./mill mill.scalalib.scalafmt/` 2. `./mill mill.kotlinlib.ktlint.KtlintModule/` can now be called via `./mill mill.kotlinlib.ktlint/` 3. `./mill mill.javalib.palantirformat.PalantirFormatModule/` can now be called via `./mill mill.javalib.palantirformat/` 4. `./mill mill.idea.GenIdea/` can now be called via `./mill mill.idea/` This removes a huge source of verbosity from the Mill command line interface, and basically fixes one of Mill's oldest issues #299 by default. Referencing external modules via their package path is sufficiently concise that it basically removes the need for defining your own `def` external module aliases, though you can always define your own aliases to make it more concise still if you so desire For cases where there is more than one `ExternalModule` in a single `package`, they will need to be called fully qualified e.g. `./mill mill.scalalib.PublishModule/` `PackageExternalModule` is the spiritual equivalent to Scala `package object` or Mill `TaskModule#defaultCommandName`, in that it allows you to take a `package` in the hierarchy and designate one direct child as the "blessed" entrypoint for that `package`. The trailing `/` in the selector is still a bit annoying and weird, and I might try making it optional a follow up PR. ## Implementation The "blessed" `ExternalModule` in a package is specified by defining a ```scala object PackageExternalModule extends mill.define.PackageExternalModule(MyExternalModule) ``` Where `MyExternalModule` is the actual `ExternalModule` in question. The `Resolve` logic when given a `foo.bar.baz/` selector first looks for the class `foo.bar.baz.PackageExternalModule$` before looking for the class `foo.bar.baz$`. This adds a tiny amount of ambiguity in what a selector `foo.bar.baz` means, but in practice I don't expect it to be a problem. I expect such collisions between normal `ExternalModule` names and `PackageExternalModule` names to happen basically never, so from a practical perspective there will only ever be one obvious target for each selector I chose the indirection of defining a separate `PackageExternalModule` object over renaming all the various external modules to `PackageExernalModule`. Renaming them is possible, but then we lose the meaningful name when referencing them in code, and breaks backwards compatibility with the fully `foo.bar.baz.MyExternalModule/` selector being passed at the command line. Using an `object PackageExternalModule` as a marker lets us avoid doing any sort of classpath scanning, which would be required if we wanted to use an `@Annotation` or marker-trait for designating the primary `ExternalModule` for a `package`. It just adds one additional `ClassLoader#loadClass` check, which is much cheaper than scanning the classpath with `classgraph` to try and find classes with particular annotations ## Testing Added a unit test case to cover this new resolution behavior, and updated all the eligible example tests to use the shorter selector. This could be backported to 0.12.x since it is backwards compatible --------- Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Commits on Apr 13, 2025
-
(Backport) Rename
PackageDefaultExternalObjectto thepackageobj……ects (#4923) Backport of #4922 This allows the shorter syntax e.g. `mill.scalalib.scalafmt.scalafmt` to be called programmatically, and brings them in line with Scala `package object`s and Mill's existing `RootModule`s --------- Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Commits on Apr 22, 2025
Commits on Apr 28, 2025
Commits on May 1, 2025
-
Fix selective execution when multiple changes are made to one module …
…under --watch (#5032) If you have two modules and run `--watch {moduleA.fooCommand,moduleB.fooCommand}`, mill will run `moduleB.fooCommand` every 2nd change to `moduleA`, even if there is no changes to `moduleB`. The problem stems from the fact that when we save the changed inputs in selective execution, we did not store the inputs from `moduleB` and when selective execution runs again (the 2nd time), it thinks that *everything* in `moduleB` changed. This fix correctly saves the state of all modules when storing the selective execution state. --------- Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Commits on May 4, 2025
-
fix: Use root qualifier in Discover macro (#5055)
without this in case there is another mill package (which is often the case for [plugins](https://github.com/disneystreaming/smithy4s/blob/series/0.18/modules/mill-codegen-plugin/src/smithy4s/codegen/mill/Smithy4sModule.scala#L17)) following error occurs during macro expansion: ``` [error] [millCodegenPlugin0_12] /home/kghost/workspace/smithy4s/modules/mill-codegen-plugin/src/smithy4s/codegen/LSP.scala:30:32: object define is not a member of package smithy4s.codegen.mill [error] [millCodegenPlugin0_12] lazy val millDiscover = mill.define.Discover[this.type] [error] [millCodegenPlugin0_12] ^ [error] [millCodegenPlugin0_12] one error found [error] [millCodegenPlugin0_12] (millCodegenPlugin0_12 / Compile / compileIncremental) Compilation failed [error] Total time: 1 s, completed May 4, 2025, 12:34:05 AM ``` Co-authored-by: ghostbuster91 <ghostbuster91@users.noreply.github.com> Pull request: #5055
Loading
This comparison is taking too long to generate.
Unfortunately it looks like we can’t render this comparison for you right now. It might be too big, or there might be something weird with your repository.
You can try running this command locally to see the comparison on your machine:
git diff 0.12.10...0.12.11