[
https://issues.apache.org/jira/browse/MSHADE-391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MSHADE-391:
---------------------------------
Description:
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}}|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.
was:
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.
> 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}}|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)
