[
https://jira.codehaus.org/browse/MSHADE-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Veithen updated MSHADE-105:
-----------------------------------
Attachment: mshade-105-test.zip
I've attached a sample project that shows the issue. It creates a shaded JAR
from commons-io and then embeds that JAR into an OSGi bundle using
maven-bundle-plugin from Apache Felix.
With maven-shade-plugin 1.5 the generated manifest looks as follows (see
bundle/target/classes/META-INF/MANIFEST.MF):
Manifest-Version: 1.0
Built-By: veithen
Created-By: Apache Maven Bundle Plugin
Import-Package: org.apache.commons.io,org.apache.commons.io.comparator
,org.apache.commons.io.filefilter,org.apache.commons.io.input,org.apa
che.commons.io.output,test
Bnd-LastModified: 1331401786401
Export-Package: test
Bundle-Version: 1.0.0
Bundle-Name: bundle
Bundle-ClassPath: .,shaded-jar-1.jar
Build-Jdk: 1.5.0_30
Bundle-ManifestVersion: 2
Bundle-SymbolicName: test.bundle
Tool: Bnd-0.0.357
Embed-Dependency: *
One can see that there are still references to the original
org.apache.commons.io package. With 1.6-SNAPSHOT the manifest looks as expected:
Manifest-Version: 1.0
Built-By: veithen
Created-By: Apache Maven Bundle Plugin
Import-Package: test
Bnd-LastModified: 1331401716142
Export-Package: test
Bundle-Version: 1.0.0
Bundle-Name: bundle
Bundle-ClassPath: .,shaded-jar-1.jar
Build-Jdk: 1.5.0_30
Bundle-ManifestVersion: 2
Bundle-SymbolicName: test.bundle
Tool: Bnd-0.0.357
Embed-Dependency: *
> Classes processed by the relocator still have references to the original
> classes in their constant pools
> --------------------------------------------------------------------------------------------------------
>
> Key: MSHADE-105
> URL: https://jira.codehaus.org/browse/MSHADE-105
> Project: Maven 2.x Shade Plugin
> Issue Type: Bug
> Affects Versions: 1.4
> Reporter: Andreas Veithen
> Assignee: Olivier Lamy
> Priority: Minor
> Fix For: 1.6
>
> Attachments: constant-pool.patch, javap2.txt, javap.txt,
> mshade-105-test.zip
>
>
> DefaultShader uses the ClassWriter(ClassReader, int) constructor instead of
> ClassWriter(int). According to the ASM Javadoc, this has the following
> effects:
> "- The constant pool from the original class is copied as is in the new
> class, which saves time. New constant pool entries will be added at the end
> if necessary, but unused constant pool entries won't be removed.
> - Methods that are not transformed are copied as is in the new class,
> directly from the original class bytecode (i.e. without emitting visit events
> for all the method instructions), which saves a lot of time. Untransformed
> methods are detected by the fact that the ClassReader receives MethodVisitor
> objects that come from a ClassWriter (and not from a custom ClassAdapter or
> any other ClassVisitor instance)."
> The second item is actually not applicable in the case of DefaultShader
> because the entire class needs to be transformed anyway. On the other hand,
> the first item implies that the constant pool of the transformed class will
> still have references to the original classes. This can be seen from the
> attached "javap.txt" file (produced by javap on a class relocated by
> maven-shade-plugin): the relocation adds new entries at the end of the
> constant pool, but the original entries are still present.
> Since the original entries are no longer referenced anywhere in the class,
> this has no consequences at runtime. However, some tools such as Felix'
> maven-bundle-plugin use the constant pool to determine the dependencies of a
> class. The effect is that if such a shaded JAR is embedded into a bundle
> using maven-bundle-plugin, it will generate spurious Import-Package
> instructions referring to the original package names. An example of this is
> described in AXIS2-5145.
> The solution to this problem is simply not to pass the ClassReader object to
> the ClassWriter constructor. With this change, the constant pool is properly
> cleaned up (see the attached "javap2.txt" file).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
