> 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
