maven-dependency-plugin
maven-dependency-plugin copied to clipboard
adding sort option for build-classpath
For now it is a proposal since jira status is quite weird regarding that but I fail to see how to have a deterministic build without such an option so proposing a solution and will create tickets if there is an agreement on the solution.
Following this checklist to help us incorporate your contribution quickly and easily:
- [ ] Make sure there is a JIRA issue filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes.
- [ ] Each commit in the pull request should have a meaningful subject line and body.
- [ ] Format the pull request title like
[MDEP-XXX] - Fixes bug in ApproximateQuantiles, where you replaceMDEP-XXXwith the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
- [ ] Run
mvn clean verifyto make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the integration tests successfully (
mvn -Prun-its clean verify).
If your pull request is about ~20 lines of code you don't need to sign an Individual Contributor License Agreement if you are unsure please ask on the developers list.
To make clear that you license your contribution under the Apache License Version 2.0, January 2004 you have to acknowledge this by using the following check-box.
-
[ ] I hereby declare this contribution to be licenced under the Apache License Version 2.0, January 2004
-
[ ] In any other case, please file an Apache Individual Contributor License Agreement.
What is the benefit? The same request keeps popping up with Tomcat and the classpath does not rely on order.
@michael-o well you should consider these points:
- if not sorted then nothing is reproducible in java world so the build-classpath mojo requires a postprocessor or replacement for all consumer of the output (downstream mojo, custom runtime code etc) - including a
java -cp @<cp from build-classpath> MyMainkind of commands or jib based builds or CDS archive build ... - tomcat has solutions for that - mainly custom webapploader/classloader or OS specific stuff - even if tomcat itself does not want to do the integration out of the box for the same reason so even if the project rejects the features some users rely on it
I'm not 100% sure if we need more flexibility on the ordering but not sorting the output is quite useless for any pipeline relying on the classpath dump (it is fine for other use cases) so hope we can find a way to sort somehow whatever the order is.
Hope it makes sense.
For debug purposes I understand that a canonization makes sense, but bit for the actual class path. That should always work.
Classpath is a sorted list in the jvm so order is important for classes and resources. Custom classloaders are unrelated to the classpath and dont have to respect that even if all "true" urlclassloaders will. But here we speak of classpath so order is a thing.
Classpath is a sorted list in the jvm so order is important for classes and resources. Custom classloaders are unrelated to the classpath and dont have to respect that even if all "true" urlclassloaders will. But here we speak of classpath so order is a thing.
Ordered != sorted. Where is is sort? Show me!