maven-shade-plugin
maven-shade-plugin copied to clipboard
[MSHADE-406] Support multi release jars
NOTE At this point this is only testcases for https://issues.apache.org/jira/browse/MSHADE-406
I'm looking into if I can figure out how to fix this problem. If i can't (which is quite likely) then the next person at least has these tests as a starting point.
What I concluded so far is that the (quite logical) key assumption (in the entire codebase) that a single class is in a single file ... is no longer valid.
So a single class in a Jar can be
nl/basjes/maven/multijdk/App.class
META-INF/versions/11/nl/basjes/maven/multijdk/App.class
META-INF/versions/17/nl/basjes/maven/multijdk/App.class
- So what classes are needed? That are the needed for all of these combined.
- Relocating? All must be relocated in the same way.
- Minimize? Remove all of these variants.
Following this checklist to help us incorporate your contribution quickly and easily:
- [x] 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.
- [x] Each commit in the pull request should have a meaningful subject line and body.
- [x] Format the pull request title like
[MSHADE-XXX] - Fixes bug in ApproximateQuantiles, where you replaceMSHADE-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. - [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
- [x] Run
mvn clean verifyto make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] 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.
-
[x] I hereby declare this contribution to be licenced under the Apache License Version 2.0, January 2004
-
[x] In any other case, please file an Apache Individual Contributor License Agreement.
After some more testing I think an upstream change in https://github.com/tcurdt/jdependency is needed.
Simply put: all classes defined in https://github.com/nielsbasjes/maven-shade-plugin/tree/MSHADE-406-MultiReleaseJar/src/it/setup/multiReleaseJar under META-INF/versions/ are simply not returned in the list of classes for the artifact.
CC: @tcurdt
@nielsbasjes Feel free to open an issue with a testcase.
TBH I don't see anything being filtered yet.
https://github.com/tcurdt/jdependency/blob/master/src/main/java/org/vafer/jdependency/Clazzpath.java#L136
I guess the question is whether the JarInputSteam does provide access to classes in META-INF.
A quick test could be to extract the jar and add the classpath unit not via jar but via filesystem.
@tcurdt I'll have a look if I can make it all work. I have found the filter. https://github.com/tcurdt/jdependency/blob/master/src/main/java/org/vafer/jdependency/Clazzpath.java#L71
The '-' is part of the META-INF/versions/ that blocks it.
I'm having a go at it.
The '-' is part of the
META-INF/versions/that blocks it.
True! Good find.
@tcurdt First attempt https://github.com/nielsbasjes/jdependency/tree/MultiReleaseJar
Output seems like a step in the right direction:
nl.basjes.maven.multijdk.SpecificToJava17 in {17=META-INF/versions/17/nl/basjes/maven/multijdk/SpecificToJava17.class}
nl.basjes.maven.multijdk.Unused in {11=META-INF/versions/11/nl/basjes/maven/multijdk/Unused.class, 17=META-INF/versions/17/nl/basjes/maven/multijdk/Unused.class, 8=nl/basjes/maven/multijdk/Unused.class}
nl.basjes.maven.multijdk.App in {11=META-INF/versions/11/nl/basjes/maven/multijdk/App.class, 17=META-INF/versions/17/nl/basjes/maven/multijdk/App.class, 8=nl/basjes/maven/multijdk/App.class}
nl.basjes.maven.multijdk.Main in {8=nl/basjes/maven/multijdk/Main.class}
nl.basjes.maven.multijdk.OnlyUsedInJava17 in {11=META-INF/versions/11/nl/basjes/maven/multijdk/OnlyUsedInJava17.class}
nl.basjes.maven.multijdk.SpecificToJava11 in {11=META-INF/versions/11/nl/basjes/maven/multijdk/SpecificToJava11.class}
nl.basjes.maven.multijdk.AbstractJavaVersion in {8=nl/basjes/maven/multijdk/AbstractJavaVersion}
nl.basjes.maven.multijdk.JavaVersion in {11=META-INF/versions/11/nl/basjes/maven/multijdk/JavaVersion.class, 8=nl/basjes/maven/multijdk/JavaVersion.class}
Current status: A basic shade and a shade+minimize seem to work. Relocated does not yet work.
Next hurdle: Almost all of the code assumes the name of the class file is the same as the package+class name.
Current state is with https://github.com/tcurdt/jdependency/pull/209 installed almost all tests (including several new tests that do shading, relocating and minimizing a multirelease jar) pass. Only a few around the MANIFEST.MF tests currently fail.
[INFO] Passed: 79, Failed: 3, Errors: 0, Skipped: 1
[INFO] -------------------------------------------------
[ERROR] The following builds failed:
[ERROR] * projects/MSHADE-373/pom.xml
[ERROR] * projects/MSHADE-183/pom.xml
[ERROR] * projects/manifest-transformed/pom.xml
[INFO] -------------------------------------------------
[WARNING] The following builds were skipped:
[WARNING] * projects/MSHADE-185/pom.xml
With https://github.com/tcurdt/jdependency/pull/209 installed locally this now works on my machine.
Looking good and merged. For a release it still needs fixes for Windows though it seems.
https://ci.appveyor.com/project/tcurdt/jdependency/builds/48559371
From the thread it looked like this was resolved over a year ago, but it has yet to be merged in. I'm facing this issue, is there any planned movement here?
@parnmatt should have been released with jdependency-2.10 about a year ago
And it's in the pom on master
https://github.com/apache/maven-shade-plugin/blob/master/pom.xml#L172
Thanks @tcurdt, I came from MSHADE-406 which links here. It currently says open and unresolved, thus I made an assumption.
Resolve #652
Resolve #652