[MSHADE-406] Support multi release jars

[nielsbasjes]

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:

• 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 [MSHADE-XXX] - Fixes bug in ApproximateQuantiles,
  where you replace MSHADE-XXX with 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 verify to 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.

[nielsbasjes]

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

[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.

[nielsbasjes]

@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.

[tcurdt]

The '-' is part of the META-INF/versions/ that blocks it.

True! Good find.

[nielsbasjes]

@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}

[nielsbasjes]

Current status: A basic shade and a shade+minimize seem to work.
Relocated does not yet work.

[nielsbasjes]

Next hurdle: Almost all of the code assumes the name of the class file is the same as the package+class name.

[nielsbasjes]

Current state is with tcurdt/jdependency#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

[nielsbasjes]

With tcurdt/jdependency#209 installed locally this now works on my machine.

[tcurdt]

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