Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

multi-module dependency resolving broken (duplicates) #211

Closed
francisdb opened this issue Mar 8, 2018 · 10 comments · Fixed by #261
Closed

multi-module dependency resolving broken (duplicates) #211

francisdb opened this issue Mar 8, 2018 · 10 comments · Fixed by #261

Comments

@francisdb
Copy link
Contributor

francisdb commented Mar 8, 2018

I seem to be getting 2 versions of the same dependency in the classpath, should mill not be taking care of these?

mill show foo.compileClasspath
...
"path": "/Users/francisdb/.coursier/cache/v1/https/repo1.maven.org/maven2/com/typesafe/akka/akka-actor_2.12/2.5.3/akka-actor_2.12-2.5.3.jar"
...
"path": "/Users/francisdb/.coursier/cache/v1/https/repo1.maven.org/maven2/com/typesafe/akka/akka-actor_2.12/2.5.11/akka-actor_2.12-2.5.11.jar"

simple test case available here:
https://github.com/francisdb/milltest

@lihaoyi
Copy link
Member

lihaoyi commented Mar 8, 2018

maybe; what's your build?

@francisdb
Copy link
Contributor Author

francisdb commented Mar 8, 2018

My build is a big 20+ module project, where some modules bring in akka through a transitive dependency from it's own dependency

Anything more specific you want me to mention?
Can you also clarify maybe, in what case should mill allow this?

@lihaoyi
Copy link
Member

lihaoyi commented Mar 9, 2018

can you poke around the build using describe/inspect and show to see where the various versions come from? Using describe tells you what the parents of a task are and show tells you what the value is. It should be pretty quick to figure out where the various copies of Akka are coming from

@francisdb
Copy link
Contributor Author

I made it even worse by adding more dependencies to other versions of akka

On the modules level
logging depends on core

On the ivy level
core has a direct dependency on akka-actor_2.12-2.5.4
core has a transitive dependency on akka-actor_2.12-2.5.3
logging has a dependecny on akka-actor_2.12-2.5.11

but when I do the following

logging.compileClasspath().foreach(println)
...
PathRef(/Users/francisdb/.coursier/cache/v1/https/repo1.maven.org/maven2/com/typesafe/akka/akka-actor_2.12/2.5.3/akka-actor_2.12-2.5.3.jar,true,426226507)
...
PathRef(/Users/francisdb/.coursier/cache/v1/https/repo1.maven.org/maven2/com/typesafe/akka/akka-actor_2.12/2.5.4/akka-actor_2.12-2.5.4.jar,true,-2030674072)
...
PathRef(/Users/francisdb/.coursier/cache/v1/https/repo1.maven.org/maven2/com/typesafe/akka/akka-actor_2.12/2.5.11/akka-actor_2.12-2.5.11.jar,true,2056048751)
...

Using sbt akka-actor_2.12-2.5.3 and akka-actor_2.12-2.5.4 are evicted in favor of akka-actor_2.12-2.5.11

@lihaoyi
Copy link
Member

lihaoyi commented Mar 14, 2018

I don't really know any reason mill should allow it, but there might be bugs, hence maybe.

So you have a big 20+ module project; just delete everything you can while reproducing this bug. You shouldn't even need any source files present, just the build.sc, and it should be pretty quick to bisect.

Once the project is minimized, let me know and maybe the problem will be clearer. Perhaps you may even spot the issue yourself

@francisdb
Copy link
Contributor Author

francisdb commented Mar 21, 2018

I created a very simple reproducer (just the build file needed) here: https://github.com/francisdb/milltest

Direct dependencies are deduplicated, module-transitive ones are not

@francisdb
Copy link
Contributor Author

the main issue seems to be here
https://github.com/lihaoyi/mill/blob/cb30f1c42c818b2a2b1e216823ca09c8430da5f9/scalalib/src/mill/scalalib/ScalaModule.scala#L175

You can't just use the upstreamRunClasspath, it needs to be re-resolved together with the current module dependencies to make sure there are no duplicates.

@francisdb francisdb changed the title multiple versions of same dependency in classpath multi-module dependency resolving broken (duplicates) Mar 21, 2018
@lihaoyi
Copy link
Member

lihaoyi commented Mar 22, 2018

@francisdb nice find, yeah we probably should restrict upstreamRunClasspath to compile resources and unmanagedDependencies only, since ivyDeps and friends will all get aggregated separately and resolved using coursier. Can you send a PR?

@francisdb
Copy link
Contributor Author

I fear I don't feel enough at home with all these scopes and dependencies to be able to fix this.

lihaoyi added a commit that referenced this issue Mar 27, 2018
…odule's `runClasspath`; only the ivy coordinates are aggregated, and every module resolves it's own set of ivy jars using coursier, which avoids duplicate jars entering the classpath through ivy

Fixes #211
@lihaoyi lihaoyi mentioned this issue Mar 27, 2018
@francisdb
Copy link
Contributor Author

@lihaoyi I can confirm this to be fixed!

shengc pushed a commit to shengc/mill that referenced this issue Apr 2, 2018
…odule's `runClasspath`; only the ivy coordinates are aggregated, and every module resolves it's own set of ivy jars using coursier, which avoids duplicate jars entering the classpath through ivy

Fixes com-lihaoyi#211
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants