Tobias Roeser

Thanks for the report. Looks like we also need to mask illegal characters in cross values. As a work around, you can skip the `dummy` modules. ```diff --- a/build.sc +++...

Looks like #4052 is only fixing the use side of this problem. Hence the new duplicate reported in #4371. https://github.com/com-lihaoyi/mill/pull/4052/files#diff-2b601da62851663bf0f9429195310d82df029448cc2f404c421798601585fb10R683-R685 Instead, we need to mask all cross values when materializing...

* For the build failures, see https://github.com/com-lihaoyi/mill/pull/3192

Probably related: * https://github.com/coursier/coursier/issues/3122

Maybe, we should introduce a `interactive` flag in `Task.Command` such that we can detect early and generically, that the user is supposed to run with `--interactive`. (We could even automatically...

I think just avoiding re-exports is the correct thing to do. I was never a fan of the re-exports under `javalib` for exactly this reasons and I think I said...

We try to provide the most Language specific user experience, and having properly cut packages which of course requires the user to import it, is a consequence of Mill using...

I think the first step should be detecting conflicting dependencies. Instead of a BOM, we should start adding version constraints (e.g. all versions compatible to our own API) in addition...

As far as I understand it, there are roughly three ways to specify a version: A dependency with 1. a simple version 2. no version 3. a version range Each...

So the main question is: Does a BOM version always wins, or is it only used to fill dependencies with an empty version? Will coursier still pick the newest verison...