Tobias Roeser

Dependencies to Mill itself should be specified with `Provided` scope. I think they are currently in the default `Compile` scope. Also, depending on Mill `0.11.7` instead of `0.11.0` will effectively...

> > Dependencies to Mill itself should be specified with `Provided` scope. > > What's the benefit of that over using the compile scope? I understand the point about pinning...

Interesting finding, thanks for reporting! I think until we improve the migrator, we should at least warn the user if we detect multiple test frameworks. But IIRC, sbt is auto-detecting...

No, this selects the JVM/JDK to use. This also means, without further configuration, compiled class files target this JVM version or newer. But you typically want to explicitly set your...

Maybe we should add an explicit `jvmTarget` task to `JavaModule`. It's something almost any library author needs to configure at some point. Since this is something coherent for all derived...

@lihaoyi, you're right. The OP snippet does select the toolchain, not the `--release` flag I was referring to.

@lihaoyi > I think the new `mill.define.BuildCtx` module is basically this. Oh, I didn't realized, that it provides tasks. `BuildCtx` looks a bit unfinished as it has multiple `public def`s...

I think it might be worth to consider to add the repositories from the YAML-frontmatter to `JavaModule` by default.

Looks like we lost `mill.runner.MillBuild` external module, which allowed us to get the meta build level count. * introduced at: https://github.com/com-lihaoyi/mill/pull/2719 * removed at: https://github.com/com-lihaoyi/mill/pull/3717 We currently have no way...

Haoyi already started something: https://github.com/com-lihaoyi/os-lib/pull/257