[
https://issues.apache.org/jira/browse/MSHADE-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349135#comment-17349135
]
Alexander Kriegisch commented on MSHADE-391:
--------------------------------------------
If anybody would like to test my fix with regard to this issue (also includes
the fix for MSHADE-252), you can use it like this:
{code:xml}
<pluginRepositories>
<!-- TODO: Remove after upstream release for Maven Shade with fix for
MSHADE-252 -->
<pluginRepository>
<id>aspectj-dev</id>
<name>AspectJ artifacts on aspectj.dev</name>
<url>https://aspectj.dev/maven</url>
<snapshots>
<enabled>true</enabled>
</snapshots>
</pluginRepository>
</pluginRepositories>
<!-- (...) -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>3.2.4.MSHADE-252-391</version>
</plugin>
{code}
> Do not modify class files, if nothing was relocated
> ---------------------------------------------------
>
> Key: MSHADE-391
> URL: https://issues.apache.org/jira/browse/MSHADE-391
> Project: Maven Shade Plugin
> Issue Type: Improvement
> Affects Versions: 3.2.4
> Reporter: Alexander Kriegisch
> Priority: Major
>
> h3. Preface
> This issue relates to my [mailing list
> question|https://www.mail-archive.com/[email protected]/msg143192.html]
> and the subsequent, fruitless meta discussion there, where nobody actually
> said anything about the problem at hand. So just like in the case of
> MSHADE-252, I fixed the problem by myself. Please see the attached pull
> request.
> h3. Problem description
> When running Maven Shade with relocation, it works nicely. When
> comparing JARs before and after relocation, I was surprised to see that Shade
> not just modifies the relocated classes and classes referencing them, but
> also a bunch of completely unrelated classes. Their byte code is slightly
> different, probably still does the same thing, but it makes comparisons and
> sanity checks or automatic verification steps harder than necessary.
> BTW, the same Shade execution also relocates the sources (running my version
> with fixed MSHADE-252). In this case, only changed source files referencing
> the relocated classes are being changed, just like I would have expected.
> h3. Problem analysis
> Maven Shade internally uses ASM's {{ClassRemapper}} and defines a custom
> {{Remapper}} subclass, which takes care of relocation, partially doing the
> work by itself and partially delegating to the ASM parent class. An ASM
> {{ClassReader}} reads each class file from the original JAR and
> *unconditionally* writes it into a {{ClassWriter}}, plugging in the
> transformer.
> This transformation, even if not a single relocation (package name mapping)
> takes place, often leads to binary differences between original class and
> transformed class, because constant pool or stack map frames have been
> adjusted, not changing the functionality of the class, but making it look
> like something changed when comparing class files before and after the
> relocation process.
> h3. Solution / improvement
> When reading each class file from the original JAR, we can store a copy in a
> byte array. We also need to adjust the relocation process such that a flag is
> set whenever anything is being relocated (package name change, textual or
> binary references to other relocated classes). After the transformation is
> done, Maven Shade can decide whether to write the original class file or the
> transformed one. This avoids writing transformed class files, even though no
> relocation has taken place for those files.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
