>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
