Support for (transitive) dependency management / override

[lefou]

Mill currently has no way to influence the transitive version management. Since we already have the CoursierModule.mapDependencies task, this is no issue for projects that build applications. But for libraries projects, controlling of downstream dependency selection might be a useful feature.

Once we add such feature, we need to make sure, that dependency resolution behaves consistent between inner-module and ivy-module dependencies. Also, we want to write this information in pom.xml under <dependencyManagement> as well as into ivy.xml as dependency override section.

Also sbt does not have this features. It allows to force or specify (transitive) dependency versions, which is what we can do with mapDependencies. But it does not support to generate dependencyManagement-sections in pom.xml.

Some links:

• Maven: https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#dependency-management
• Ivy: https://ant.apache.org/ivy/history/2.5.0/ivyfile/override.html
• sbt: https://www.scala-sbt.org/1.x/docs/Library-Management.html

[alexarchambault]

Mill currently has no way to influence the transitive version management.

There's at least two:

• adding dependencies ensures their version is >= to the added one
• exclusions

Post-processing dependencies is somewhat harmful: if users publish a module where they post-processed dependencies this way, users of the published module won't benefit from the post-processing (while they do benefit of the two points above, which do end up in the POM).

And https://github.com/coursier/coursier/issues/1390 won't change that: if a project uses it and is published, versions aren't forced the same way for its users (when pulling dependencies that have a BOM, the BOM is only used to fill "holes", that is missing versions in the POM - no version is otherwise forced whatsoever). https://github.com/coursier/coursier/issues/1390 is not a way to share forced dependencies for library authors / users, unless users explicitly add the BOM to their project (and if all libraries each supply their own BOM, it's likely some might conflict…)

[lefou]

Thanks for your comment, @alexarchambault.

Mill currently has no way to influence the transitive version management.

There's at least two:

* adding dependencies ensures their version is >= to the added one

* exclusions

Adding dependencies has the downside, that you misuse the mechanism, as you most likely list dependencies which are only transitively needed. There is a high risk those entries run out of date. The reasons may vary, but will be most likely that the upstream dependencies have changed. There is also the somewhat smaller risk to produce incompatibilities combinations.

The dependencyManagement as known from Maven isn't affected by this issue. It will only take control for dependency which are actually part of the (direct and transitive) dependency set.

Exclusions on the other side, are already propagated to the exported pom.xml in current Mill.

Post-processing dependencies is somewhat harmful: if users publish a module where they post-processed dependencies this way, users of the published module won't benefit from the post-processing (while they do benefit of the two points above, which do end up in the POM).

This is essentially the motivation for this very issue and also coursier/coursier#1390. We need a dedicated way to manage dependencies that transcends into package management like Maven (pom.xml) or Ivy.

And coursier/coursier#1390 won't change that: if a project uses it and is published, versions aren't forced the same way for its users (when pulling dependencies that have a BOM, the BOM is only used to fill "holes", that is missing versions in the POM - no version is otherwise forced whatsoever). coursier/coursier#1390 is not a way to share forced dependencies for library authors / users, unless users explicitly add the BOM to their project (and if all libraries each supply their own BOM, it's likely some might conflict…)

I think there is probably a still too vague understanding of the details of coursier/coursier#1390. I envision in it exactly that: a way to let coursier know, that I want to add some dependencies to my current dependencyManagement section. And of course, I want to add those dependencies either directly or by importing an external BOM dependency. The effect should be the same: I can better control what dependencies and versions should be used or excluded. And this management is also effective to downstream users, as we export it as part of the pom.xml.