Tobias Roeser

This has the issue that the holder (`crossScalaVersion`) of the cross parameter is fixed. And would collide with most use cases in which more than one cross axis is involved....

Could you please verify, that it does not happen with Mill 0.10.0-M3? I've the vague feeling it's related to the fact it's built and bundled with Scala 2.13.6. I can't...

@pbuszka Thanks for testing. As we changed the underlying Ammonite version (which is also the reason why 0.10.x is binary incompatible), we need to investigate, if this also happens with...

On a first glance, it looks like when resolving the ivy deps of `javaapi` we also resolve all transitive deps from other modules, which include also scala dependencies. But in...

2 workaround come to my mind: * make the `javaapi` project a `ScalaModule` and adapt the `artifactSuffix` to be empty * write the dependency as pure java dependency: ivy"org.typelevel:cats-scalaBinVersion}:2.1.1"

We could transform ivy-deps of other modules to be just "java" dependencies without any cross-version semantic. This can of course lead to issues too. Thinking a bit more about this...

I currently hit this issue again when working on a polyglot project, which has Java, Java + AspectJ, Scala and Kotlin modules. But I think this issue will hit us...

I think each module should implement some checks, e.g. a `ScalaModule` should check that each transitively module dependency has a compatible or event the same scala version selected. Other modules,...

I haven't looked at the code right now, but we have a defined way to translate each mill-dependency to a coursier-dependency. I think it's `resolveCoursierDependency`. It's probably worth a POC...

Bah, GH, you're drunk.