New features and breaking changes in 0.12.x

[lefou]

Below you find a new feature or a breakage per main-comment. Discussion should happen in the matching sub-comments.

The development of Mill 0.12 starts with the tag 0.12.0-M0 in the main branch. It is planned to keep binary compatibility to Mill 0.11, so that you can keep using plugins built for Mill 0.11. Therefore we also keep the binary platform to 0.11, which means, thirdparty plugins will keep using the _mill0.11 suffix in their artifact name.

Maintenance of Mill 0.11 will happen for a rather short time in the 0.11.x branch, as we hope that it's easy for most users to just switch over to 0.12.

Please open a new issue or a discussion, if you face major road blocks when switching from 0.11 to 0.12!

[lefou]

Mill 0.12 will requires Java 11.

• Bump Requests-Scala to 0.9.0 #3282

[lefou]

Mill 0.12 supports submodules defined in module.sc package.mill files in sub-directories.

• Support module.sc files in subfolders #3213

[lefou]

Mill 0.12 now enables parallel builds by default.

• Turn on parallelism by default, ensure Commands always run serially at the end #3265

[lihaoyi]

Mill 0.12 runs test suites with the subprocess working directory set to empty sandbox folders by default, rather than in the project root

• Make TestModule#test run in T.dest folder by default #3347

[lihaoyi]

We'll also be moving the Mill process os.pwd to a sandbox folder by default, to encourage proper use of T.sources, T.dest and PathRefs rather than directly reading files off of disk

• Move Mill process working directory to sandbox #3367

[lefou]

Dropped Support for Scala Native 0.4

• as part of Test suite overhaul #3398

[lefou]

The name of the BaseModule is no longer build, but build.package.

As a result, when using mill.resolve.Resolve.resolve API, you may need to change your code.

A possible code change might look like this:

 mill.resolve.Resolve.Tasks.resolve(
-    build,
+    build.`package`,
     taskNames,
     SelectMode.Separated
   )

[lihaoyi]

This should be no longer necessary once #3426 lands

[lefou]

Nice to see that we don't introduce extra use of package objects. While experimenting, I think I witnessed various strange incremental compiling issues caused by package objects.

[lihaoyi]

Yeah I hit a bunch of issues. I assume some are fixed in Scala3, and package objects do seem to fit the domain nicely, but some issues remain (e.g. the build.package thing) so maybe best to go eith normal objects for now

[lolgab]

forkEnv is now an empty Map #3442

[lefou]

Mill commands now require arguments to be passed named via ./mill mycommand --key value, rather than allowing just ./mill mycommand value.

You can pass in --allow-positional-command-args to fall back to the old behavior, or use @mainargs.arg(positional = true) on individual parameters

• Make Mill commands require named CLI parameters by default #3431

[lihaoyi]

The type parameter for Discover[T] was removed in 40b1920, leaving just Discover. The type parameter was unused, and removing it is binary compatible although not source compatible. For migration purposes, you should be able to convert any Discover[T] types to just Discover and things should continue working as before

[gamlerhart]

I maybe missed it somewhere, but a breaking change also?
The RootModule must now be called package.

[lefou]

Correct. And since package is a reserved keyword, you need to mask it in Scala.

object `pakcage` extends RootModule {
}

[nafg]

Couldn't that just be

package object whatever extends RootModule

?

[lefou]

@nafg No. We evaluated that, but it has issues. Also, package objects will go in Scala 3.

[lefou]

JavaModule.runIvyDeps are now transitive.

• runIvyDeps should be transitive for consistency with Maven resolution #3761
• Make runtime deps transitive #3774

[Tang-Haojin]

I have a file submodule/common.sc, and in previous version, I can use import $file.submodule.common. Now I get

[error] object submodule is not a member of package build_

How should I modify my build.mill?

[lefou]

Not yet, but if we agree, a build.{sc,mill} in a sub-directory isn't an issue, we could change it to a warning. @lihaoyi WDYT?

[lihaoyi]

Works for me

[Readon]

Thanks. Would you put it in the next release?

[lefou]

It depends on how fast someone can prepare a PR. I think the next release is rather ripe.

[lefou]

I opened an issue

• Don't fail, if a build.{sc,mill} is found in sub-directories #3921

[Quafadas]

I hit a case where tests classes failed on 0.12.0, but worked on 0.11.12. Worked in CI, but not locally, which was odd.

In my build, I was adding this flag to forkArgs.

val vecIncubatorFlag = Seq("""--add-modules=jdk.incubator.vector""")

but hitting this;

1 tasks failed
vecxt.jvm.test.discoveredTestClasses java.lang.IllegalAccessError: superclass access check failed: class jdk.incubator.vector.Vector (in unnamed module @0x24e544f9) cannot access class jdk.internal.vm.vector.VectorSupport$Vector (in module java.base) because module java.base does not export jdk.internal.vm.vector to unnamed module @0x24e544f9

The workaround seems to be adding the jvm flag to mill opts, but this might be expected behaviour. Discord discussion;
https://discord.com/channels/632150470000902164/1295786923410984981/1299305997898354749

The error looks like it is coming from the Mill JVM before it forks off the test subprocess
from the discoveredTestClasses task
discoveredTestClasses runs test discovery in-process before forking off the subprocesses
not sure why it's causing issues, but you can probably solve it by adding --add-modules=jdk.incubator.vector to .mill-jvm-opts