What Tamas is saying with "Maven is not the tool that overrides user input ", is that Maven always had the following behavior: if a direct dependency is explicitly defined by the user, the version defined will be the one resolved, even if a transitive dependency specifies a higher one, in which case the dependency is downgraded.
For the reproducer, there are multiple ways to fix the problem: * explicitly define the version in the pom to 5.0.1. -> 5.0.1 will be used * use a version range [3.0,7.0.0-rc1) -> 6.0.0 will be used * remove the dependency and use -Daether.conflictResolver.versionSelector.selectionStrategy=highest -Daether.dependencyCollector.bf.skipper=versioned -> 5.0.1 will be used Currently, we are advocating the first option. I'm not opposed to discussing a change that would make "highest" strategy the default, but this will probably break a bunch of applications which rely on the actual behavior, so this needs to be discussed and planned. And that alone, would not fix the above use case. What you suggest is changing the resolver to consider direct dependencies as transitive dependencies. And maybe remove the closest/further rule, i.e. the highest always wins. Right ? Le mer. 5 nov. 2025 à 06:48, Vladimir Sitnikov <[email protected]> a écrit : > > Next, I told you many times: You should do your homework. > > Tamás, I understand you might have had a bad day. Please refresh > https://www.apache.org/foundation/policies/conduct > > >First, I demonstrated to you already how this works for transitive > dependencies. > > Please do not mix threads. If you are absolutely sure it is worth > conflating the discussions, please say that aloud. > I assumed it would be better to discuss different issues separately. > I have not heard of Maven team's opinion on > "case3-standalone-with-direct-dep" reproducer: > https://lists.apache.org/thread/lgb4t1j8z8vvn320zzo0y60qw3t5mppc > > >Maven is not the tool that overrides user input [1] and [2] > > Tamás, you quote [2], and the lines relate to org.example:svg:1.0.0 > and org.example:http:1.1.0. > I truly don't understand why you quote the lines along "Maven is not the > tool that overrides user > input". > At no point in the jarsplit example I requested Maven to alter svg or http > versions. > The example application wants to use two independent libraries: svg:1.0.0 > and http:1.1.0. > In this app, I'm fine if Maven would resolve to svg:1.0.0 and http:1.1.0. > > In practice, Maven resolves to svg:1.0.0 and http:1.1.0. > Gradle execution resolves the same svg:1.0.0 and http:1.1.0 (see [1]). > > Maven results in NoClassDefFoundError. Gradle execution succeeds. > > Could you please check the example again? > > >But there is much more to it, as Guava devs added a great deal of > >explanation of other aspects too (and history bits). > > Of course splitting a popular library is not a walk in the park. > Guava devs confirm though that Maven's inability to handle library splits > is one of the culprits when it comes to splitting Guava. > Maven could do better to lift the obstacles out. > > [1] > > https://github.com/vlsi/jarsplit/blob/b7dae3f1609b978e1a33ffa63d717bc66e45daa5/README.md#L67-L75 > [2] > > https://github.com/vlsi/jarsplit/blob/b7dae3f1609b978e1a33ffa63d717bc66e45daa5/app-maven4/pom.xml#L8-L19 > > Vladimir > -- ------------------------ Guillaume Nodet
