Hi Vladimir, Do you try to understand what you read or you just quote random sentences when they look mean?
> Guava developers say "Maven's inability to deal with old guava:20 and new guava-hash:42 being present both in the dependency tree" is a showstopper for splitting Guava into several modules. There is no link to maven there but actually java if you go one step further. Maven does its job and actually helps there in dependency convergence - even if you want to reinvent it. But ultimately Java was preventing the buggy guava design to be split easily as Tamas explained. Please stop spreading fake news everywhere and help moving forward if you do have real issues not already solved. Romain Manni-Bucau @rmannibucau <https://x.com/rmannibucau> | .NET Blog <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064> Javaccino founder (Java/.NET service - contact via linkedin) Le mer. 5 nov. 2025 à 06:47, 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 >
