1. you have all the details on the 14th/15th of oct, it explains why exec must not be used and how it makes you state wrong statements 2. if you take a knife and reverse it to cut some tomato, is it the knife fault you are hurt? no, it is the same there, this is not cause your pom is XML-valid that you use it right, Tamas explained it to you
> If you block ideas because they miss fixes for "all other issues", then you never get a new thing. I do not, I'm just saying your use case will break more than it will help in practise so it is likely not worth it. Side note: as you saw on the related issue I helped to refined it but you should get more understanding of the impacts of the dependencies and the ecosystem before shouting against everyone which tried to help you. > So far you gave zero cases when my proposal breaks things. I gave several and even the ones you quoted about jackson (I added spark - with aws client for ex - which is a trivial one) or commons. You just do not try to understand them and are too fixed on your own niche case IMHO, that's why i asking you to take the week end to come back with a fresh mind, happent to all of us at some point. 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 jeu. 6 nov. 2025 à 21:52, Vladimir Sitnikov <[email protected]> a écrit : > >2. I do love exec but it is irrelevant for your test > > I do not understand why you keep saying "exec is irrelevant for my test", > Please provide what is relevant. > I don't want to guess what would please you. > > >3. tamas gave you all tooling to do the inspection > > That toolbox-something plugin shows the same classpath as both exec and > dependency plugins. > > >4. "Both exec plugin and *maven-dependency-plugin resolve to the same > >classpath*" <- I showed your it was not the case (with reasons for a part > >and bug for another) > > This is false. > > Here's what you have shown: > > >[DEBUG] Collected project artifacts > >[org.example:lib-uses-v1:jar:1.0.0:compile, > >org.example:commons-compress:jar:1.0.0:runtime, > >org.example:lib-uses-v2:jar:2.0.0:compile, > >org.example:commons-compress-tar:jar:2.0.0:runtime, > >org.example:commons-compress-core:jar:2.0.0:runtime] > > I assume you executed commit 5e3fa1ecd3f26a2116aa83a92e85b69560a597f6 > > Dependency plugin shows the following tree: > > [INFO] --- dependency:3.9.0:tree (default-cli) @ app --- > [INFO] org.example:app:jar:1.0.0 > [INFO] +- org.example:lib-uses-v1:jar:1.0.0:compile > [INFO] | \- org.example:commons-compress:jar:1.0.0:runtime > [INFO] \- org.example:lib-uses-v2:jar:2.0.0:compile > [INFO] \- org.example:commons-compress-tar:jar:2.0.0:runtime > [INFO] \- org.example:commons-compress-core:jar:2.0.0:runtime > > The classpath for exec plugin and dependency plugin is exactly the same. > > >5. "The bug reproduces with pure Maven APIs." <- yes but depending how you > >do use it you end with different results - it enables all cases, your > >demonstration is just not a proof currently > > I use it exactly as > > https://github.com/vlsi/jarsplit/blob/b7dae3f1609b978e1a33ffa63d717bc66e45daa5/app-maven4/pom.xml > If you think the use is invalid just say that aloud. > I am tired of your accusations which miss justifications. > > The reproducer does crash in the runtime, and the reproducer uses endorsed > Maven approaches (regular dependencies, exec plugin). > > There's no weight in just saying "is just not a proof currently". Justify > it please. > > >assuming you do proove maven should be gradle you will still hit > >the other issues > > This sounds like you don't like the idea because it does not fix all > Maven's issues. > Sure the idea targets a specific pain-point which reproduces often in the > wild. > If you block ideas because they miss fixes for "all other issues", then you > never get a new thing. > > >you have way more cases it is an issue > > Hey Romain, please justify your claims. So far you gave zero cases when my > proposal breaks things. > If the only reason that makes you dislike the proposal is because Gradle > uses the same approach, > then say that aloud. I have absolutely no desire to discuss Gradle here. > > I'm here to fix Maven tool's issue, and what I suggest is an approach that > has been tested in the Java ecosystem for more than 5 years. > > Vladimir >
