You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When traversing modules, we should only collect local resources, but not include already resolved ivyDeps, as we want to resolve all transitive ivyDeps later consistently. But the included compileClasspath might already contain resolved ivyDeps. That way, we end up with multiple resolved versions of the same dependency.
Fixes#2732
We introduce a new `localCompileClasspath`, which differs from
`compileClasspath` in that it leaves out the
`transitiveCompileClasspath` from upstream modules and `resolvedIvyDeps`
from third party dependencies.
Also tried to do some cleanup of `JavaModule`, refactoring out a
`transitiveModuleCompileModuleDeps` helper to DRY things up,
re-arranging things so all the `fooModuleDeps` helpers are all together.
Tested via a new unit test
`mill.scalalib.HelloWorldTests.multiModuleClasspaths`, which fails on
master and passes on this PR. This test case asserts the overall "shape"
of the classpaths, which should help rule out an entire class of
mis-configuration w.r.t. how the classpaths are wired up
Reproduction:
classpath with Mill
0.11.2
(note the two artifacts ofcats-core_2.13
):classpath with Mill
0.10.12
(which has a single artifact ofcats-core_2.13
):The text was updated successfully, but these errors were encountered: