Vladimir Sitnikov created MNG-7852:
--------------------------------------
Summary: Use all the versions for dependency resolution rather
than "the first ones"
Key: MNG-7852
URL: https://issues.apache.org/jira/browse/MNG-7852
Project: Maven
Issue Type: Improvement
Components: Dependencies
Reporter: Vladimir Sitnikov
Currently, Maven uses "nearest first", "declared first" rules for conflict
resolution:
https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
I suggest those rules are removed since they produce hard to reason resolutions
for transitive dependencies.
Here are some examples:
1) "Nearest first". Even though the rule sounds easy, it is not something the
users can control. For instance, if the project does not use Guava library,
some of the transitive dependencies could add a dependency on Guava. The user
has no control which dependency would be "the nearest" to declare Guava, so
user has literally no way to tell which Guava version will be used.
The only workaround I see for the users is to declare Guava dependency
explicitly even though the project does not need it directly. It sounds like
Maven requires users to re-declare all the possible dependencies, including the
runtime-only ones.
2) "declared first". Of course, dependency order matters for classpath order,
however, it is not predictable in practice, and it might result in downgrading
dependencies. Imagine the project does not use Guice. However, transitive
dependencies might use Guice. At the same time, they might start using Guice
and stop using Guice, so the user can never tell which will be the first
project that uses Guice. Unfortunately, in Maven, the first project that
declares dependency wins, so it might easily be the case that the first
mention of Guice will reference outdated version that would be incompatible
with the newer one required in another dependency.
3) Here's a real-life case: Maven downgrades protobuf-java dependency causing
something like NoSuchMethodError at the runtime. The steps to reproduce is to
add dependency on dev.sigstore:sigstore-java:0.4.0. See [~hboutemy] analysis in
https://github.com/hboutemy/sigstore-maven-plugin/blob/import/analysis.md
Long story short, sigstore-java does not depend on protobuf-java directly,
however, sigstore-java depends on several third-party libraries that eventually
depend on protobuf-java. Maven's "the first wins" behaviour results in
incoherent set of protobuf dependencies on the classpath.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
