[
https://issues.apache.org/jira/browse/MSHADE-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17782989#comment-17782989
]
ASF GitHub Bot commented on MSHADE-406:
---------------------------------------
nielsbasjes opened a new pull request, #202:
URL: https://github.com/apache/maven-shade-plugin/pull/202
**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.
---
> relocated multi-release classes aren't moved to a new directory
> ---------------------------------------------------------------
>
> Key: MSHADE-406
> URL: https://issues.apache.org/jira/browse/MSHADE-406
> Project: Maven Shade Plugin
> Issue Type: Bug
> Reporter: Brian Gruber
> Priority: Major
>
> In a project in which a dependency has a multi-release jar, classes that
> match a relocation pattern and are in the {{META-INF/versions}} directories
> are not moved to the new directory structure. They are, however, rewritten so
> that the class file itself specifies the new package name.
> Sample project:
> [https://gist.github.com/bgruber/5fb045759505da5150d3e93ec5c6010e]
> The generated jar file still contains classes like this:
> {code:java}
> $ jar tf target/relocation-test-SNAPSHOT-1.0.jar | grep versions | head
> META-INF/versions/
> META-INF/versions/9/
> META-INF/versions/9/org/
> META-INF/versions/9/org/bouncycastle/
> META-INF/versions/9/org/bouncycastle/crypto/
> META-INF/versions/9/org/bouncycastle/crypto/AsymmetricCipherKeyPair.class
> META-INF/versions/9/org/bouncycastle/crypto/Digest.class
> META-INF/versions/9/org/bouncycastle/crypto/CryptoServicesRegistrar$Property.class
> META-INF/versions/9/org/bouncycastle/crypto/CryptoServicesRegistrar.class
> META-INF/versions/9/org/bouncycastle/crypto/KeyGenerationParameters.class{code}
> I expect these class files to be under
> {{META-INF/versions/9/com/dd/org/bouncycastle}}. Extracting one of them from
> the jar and examining it, the class file does appear to have been modified to
> have the new package name:
> {code:java}
> $ jar xf target/relocation-test-SNAPSHOT-1.0.jar
> META-INF/versions/9/org/bouncycastle/crypto/Digest.class
> $ javap META-INF/versions/9/org/bouncycastle/crypto/Digest.class
> Compiled from "Digest.java"
> public interface com.dd.org.bouncycastle.crypto.Digest {
> public abstract java.lang.String getAlgorithmName();
> public abstract int getDigestSize();
> public abstract void update(byte);
> public abstract void update(byte[], int, int);
> public abstract int doFinal(byte[], int);
> public abstract void reset();
> }{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
