On May 19, 2009, at 4:54 PM, David Blevins wrote:
There are two pom.xmls involved; the one that creates the shaded
module and the one that results from the shaded module. When the
"shading" is being done as part of the build the modules that depend
on the "shaded" module will get the first version of the pom.xml,
i.e. pre-shade, which contains all the dependencies we don't want
and are trying to "shade away" (i.e. get rid of). So we end up
compiling and testing with a classpath that is not the same
classpath we ship with which is risky; i.e. if we had a class that
used org.objectweb.asm.Foo it would still compile and run because
the shaded module is still pulling it in as maven is still using the
pre-shaded pom for the duration of the build. But... maven is smart
enough to publish the updated pom.xml, the post-shade version, where
the shaded dependencies are removed. So when it's not in the build
you get the published version which does not drag in the unwanted
dependencies.
FYI, bug reports have been filed for some of these oddities in the
maven-shade-plugin.
http://jira.codehaus.org/browse/MSHADE-50
http://jira.codehaus.org/browse/MSHADE-51
If you can click the "Vote for it" link it will greatly increase the
chances of them getting fixed. A while back I helped them create a
swizzle-jira report that shows the plugin issues with the highest
number of votes, so it will have a direct impact how the issues are
prioritized.
-David