[
https://issues.apache.org/jira/browse/MSHADE-391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana closed MSHADE-391.
-------------------------------
Resolution: Fixed
https://gitbox.apache.org/repos/asf?p=maven-shade-plugin.git;a=commit;h=146b87b8191651fbcab0ea1ef5bdf9746f226830
> 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
> Assignee: Tibor Digana
> Priority: Major
> Fix For: 3.3.0
>
>
> h3. Preface
> This issue relates to my [mailing list
> question|https://www.mail-archive.com/users@maven.apache.org/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}}|https://asm.ow2.io/javadoc/org/objectweb/asm/commons/ClassRemapper.html]
> 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)
