Open lefou opened 2 years ago
Mill currently has no way to influence the transitive version management.
There's at least two:
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…)
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
.
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 intoivy.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 generatedependencyManagement
-sections inpom.xml
.Some links: