Vladimir,
Le mer. 5 nov. 2025 à 10:37, Vladimir Sitnikov <[email protected]> a écrit : > Romain, > > I would appreciate if you try running jarsplit example (see [1]), or > clarify how Maven team suggests resolving it. > It is a single-pom reproducer, and it does fail with Maven in runtime no > matter what options are set. > You got several solutions in the thread, I hear you do not want to use maven but this is a different topic from my perspective. Maven enables you to control your dependency tree. It doesn't do magic making cross builds complicated for consumers, ack, and it is likely good for end users compared to gradle scripts which are hard to get right downstream. > > >There is no link to maven there but actually java if you go one step > >further > > Romain, I assume you somehow missed the link to maven. > The link is in [2] > The issue is not in maven was my point. > > 1) Chris Povirk explicitly mentions "we also worried that Maven users would > end up with" > It is a direct link to Maven tool rather than Maven ecosystem or Java or > whatever else. > Why so much projects do not have these issues? > 2) Chris Povirk explicitly mentions "...that is best solved with...Gradle" > This again contrasts Gradle tool being a solution for Maven tool's issue > Do not forget it makes $$ so even bad concepts are sometimes implemented - not all, gradle helps but do not trust blindly what you do read. > 3) As I asked a targeted question "...key culprit is Maven’s inability to > deal with..." Chris Povirk agreed. > That is a clear link from the issue to Maven tool. > Or a lack of understanding of the tool and consumers impacts. > 4) Chris Povirk explicitly mentions "We *could reconsider* someday *if the > ecosystem* were to have better support for *splitting up artifacts* in the > future." > That signals Maven tool inability to support splitting artifacts holds > Guava. > same > 5) The example in [1] fails with Maven, and the same example does not fail > with Gradle. > once again your examples are not well written - they are designed for one gradle feature - so of course they do fail write a maven extension and it would behave the same for *you* - if you do not care about downstream consumer if you care about downstream consumers you can rewrite the consumer pom but you will have other issues as we saw with maven 4 > > >But ultimately Java was preventing the buggy guava design to be split > >easily as Tamas explained. > > Romain, neither Chris, nor Tamas used the words like "Java was preventing". > Java itself does not prevent the split. It is Maven tool that does. > Gradle supports artifact splits, and it is transparent for the end-users. > You got explanations that it is just wrong: * can maven let you handle which artifacts you bring back -> yes * can maven enable you to switch artifact on the fly -> yes with extension, see remapping thread as mentionned early, likely not desired in core * can maven let you change version on the fly -> yes with extension but, as gradle, with side effects on consumers if it is not only for a one source groupId/project > > [1] > > https://github.com/vlsi/jarsplit/tree/b7dae3f1609b978e1a33ffa63d717bc66e45daa5/app-maven4 > [2] https://github.com/google/guava/issues/8079#issuecomment-3486410334 > > Vladimir >
