[ https://issues.apache.org/jira/browse/MNG-7852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Vladimir Sitnikov updated MNG-7852: ----------------------------------- Summary: Use all the versions for dependency resolution rather than "nearest first" or "declared first" (was: Use all the versions for dependency resolution rather than "the first ones") > Use all the versions for dependency resolution rather than "nearest first" or > "declared first" > ---------------------------------------------------------------------------------------------- > > Key: MNG-7852 > URL: https://issues.apache.org/jira/browse/MNG-7852 > Project: Maven > Issue Type: Improvement > Components: Dependencies > Reporter: Vladimir Sitnikov > Priority: Major > > 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)