I believe you are correct. Thanks for the bug reference. I'm pinning to 1.2.2 as well.
Best, Laird On Mon, Jan 11, 2010 at 2:19 PM, Mat Johns <m...@cyberfish.org> wrote: > I think you maybe having the same problem as me. > > It looks like when specifying a particular set of artifacts to include in > the shaded jar ... > > <artifactSet> > <includes> > <include>groupId:artifactId</include> > </includes> > </artifactSet> > > ... it excludes the current package from the final shaded jar (which I > think is a bug, as its not shading it; rather than shading into it); and as > such have filed a bug on their jira. > > http://jira.codehaus.org/browse/MSHADE-72 > > For the moment I have update my builds to pin to the 1.2.2 version ... > > <build> > <plugins> > <plugin> > <groupId>org.apache.maven.plugins</groupId> > <artifactId>maven-shade-plugin</artifactId> > <version>1.2.2</version> > ... > </plugin> > </plugins> > </build> > > ... this at least works around the issue for now. > > Regard > ~Mat > > > Laird Nelson wrote: > >> I am gently abusing the maven-shade-plugin for some code generation >> behavior. When I upgraded from version 1.2.2 to version 1.3 something >> broke. >> >> In our project, we (unfortunately IMHO) rely a lot on code generation. >> But >> we also allow our customers to write their own hand-crafted overrides of >> code. >> >> We build the generated code in one maven project, and the hand crafted >> code >> in another. >> >> At the end of this mess, our desire was to have a single jar whose "base >> layer" consists of all the generated code, which would then be seletively >> "overlaid" by the hand crafted code. This would, in other words, replace >> any generated classes with handcrafted classes where such handcrafted >> classes exist. >> >> So suppose we generate com/foo/ABase.java, and com/foo/A.java, an empty >> class that inherits from ABase.java. We create a generated.jar for that >> containing com.foo.ABase and com.foo.A. This way if the customer doesn't >> do >> anything, our system still knows about A, even though A is just empty and >> is >> effectively entirely defined by the contents of its superclass. >> >> Then in our handcrafted project, suppose that a customer has created >> simply >> com/foo/A.java. We originally had this set up so that the >> maven-shade-plugin got involved and effectively merged the two jars: after >> building the handcrafted project, which by default produces a jar with one >> class in it, namely com.foo.A, maven shade steps in and produces a shaded >> jar whose contents include the generated com.foo.ABase and the handcrafted >> com.foo.A. >> >> This all worked fine in version 1.2.2. The maven shade plugin outputs a >> warning that says effectively, "Um, hey, you're going to stomp all over an >> existing "A" class with this new "A" class you just compiled, I hope >> that's >> OK." >> >> In version 1.3, no such warning is output, and in fact the >> overlaying/overwriting does not occur. >> >> I did not read anything one way or the other in the maven-shade-plugin >> documentation which led me to believe that any aspect of this behavior was >> defined. Can someone tell me what the intended behavior is in the case >> where you wish to shade a class with the same name? In 1.3 this does not >> appear to work at all. >> >> Thanks as always for your time and for an excellent build system. >> >> Best, >> Laird >> >>
