Notice that the maven-assembly-plugin behaves exactly as I'd hoped - it has a Boolean "useProjectAttachments" for dependencySets and "attachmentClassifier" to look for an attached alternative to the main project artifact. Those are exactly the two features I added to maven-shade-plugin and maven-war-plugin.
-----Original Message----- From: Richard Sand [mailto:rs...@idfconnect.com] Sent: Wednesday, August 28, 2013 5:05 PM To: 'Maven Developers List' Subject: RE: artifact attached by plugin not appearing in subsequent plugins I always appreciate a good starwars reference. Actually there are 12 maven modules overall in this particular project, so I don't think I fear multiple modules. Could we have split the actual Jersey application classes into a separate project outside of the war project - yes, agreed. What I do object to is creating another module with no purpose other except to hold a single build plugin. That way leads to the dreaded Maven Tribbles, and nobody wants to see that...! I'm just not following where this aversion to using multiple plugins together is coming from. I really just don't get it. Can you address that? I'll concede to you that I can allow the poms to be prosper - but I'd like to approach the conversation from the angle of "why *wouldn't* we want the output artifact of one plugin to be the input artifact to another"? So all kidding aside, if this is contrary to the Tao of Maven I'd really appreciate understanding why. Thanks! -Richard -----Original Message----- From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Sent: Wednesday, August 28, 2013 4:20 PM To: Maven Developers List Subject: Re: artifact attached by plugin not appearing in subsequent plugins But you shouldn't be having java code in module 3 (as it is a war module) so that should be split in two to follow best practice... It sounds like you have multiple-module-phobia... That way is the way of fear. Fear leads to anger... Anger leads to the dark side. Embrace the many modules on the light side of the maven-force On Wednesday, 28 August 2013, Richard Sand wrote: > I thought about it, but its very complicated to obfuscate in stages > because some of the classes to be obfuscated in projects 3 and 4 rely > on the obfuscated entrypoints in project 2. > > Basically obfuscation has to be the last thing done before final > testing and assembly. > > -----Original Message----- > From: Stephen Connolly > [mailto:stephen.alan.conno...@gmail.com<javascript:;> > ] > Sent: Wednesday, August 28, 2013 3:12 PM > To: Maven Developers List > Subject: Re: artifact attached by plugin not appearing in subsequent > plugins > > Sounds like you should be obfuscating *in* module 2 and then adding > the dependency with classifier to module 3 and 4 (or do two > obfuscations in module 2 if you need different flavours) > > On Wednesday, 28 August 2013, Richard Sand wrote: > > > Hi all, > > > > Wayne, thanks for the feedback. I understand where you're coming from. > > I've written out here a concrete example of what I want to do with > > these plugins, and with maven in general wrt passing generated > > artifacts between plugins. Hopefully others will weigh in on whether > > this approach is good and maven-esque. > > > > I have 4 maven projects: > > > > 1) a global parent pom > > 2) a common API project which creates a jar > > 3) a web application project (a Jersey JAX-RS service fwiw) which > > creates a war and depends on #2 > > 4) a java client for #3 (based on JerseyClient), which also depends > > on > > #2 > > > > 1st example: In project 3, I use my obfuscation plugin on the common > > API and the generated classes. That resulting jar file needs to go > > into the WEB-INF/lib folder of the war file. My proposed change to > > the maven war plugin would make it automatically look for a > > generated jar artifact attached to the project from a previous > > plug-in and package it appropriately. The current alternative, which > > admittedly is no big deal, is to simply have the output artifact > > created by my plugin go directly into WEB-INF/lib. But adding a > > boolean config variable to maven-war-plugin to tell it to look for > > attached jars and include them seems logical as well as trivial to > > me, but this could just be because of my relative newness to all > > things Maven > > > > 2nd example: in project 4, I again use my obfuscation plugin on the > > common API and generated classes, and then want to take that > > artifact and, along with the rest of the dependencies, use the > > maven-shade-plugin to build an "uberjar". More problematic than > > example 1 above because the shade plugin only looks at artifacts and > > has no hook to include anything directly from the filesystem. So > > what I did was modify the shade 2.1 source to include a new > > configuration > parameter. For simplicy's sake I simply called it " > > alternativeInputClassifier". When present, it instructs shade to > > look for an attached artifact with the artifact name of the project, > > of type jar, and with the specified classifier, in lieu of > > processing only the main project as input. It was a very minor > > change and I'm happy to provide the diff for it. The result is that > > my pom.xml for project 4 looks like below and works beautifully. One > > pom with two > profiles: > > > > <dependencies> > > .... > > <dependency> > > <groupId>com.idfconnect.myproject</groupId> > > <artifactId>common-tools</artifactId> > > </dependency> > > </dependencies> > > <profiles> > > <profile> > > <!-- REGULAR (unobfuscated) PROFILE --> > > <id>regular</id> > > <activation> > > <activeByDefault>true</activeByDefault> > > </activation> > > <build> > > <plugins> > > <!-- BEGIN SHADE --> > > <plugin> > > > > From: Wayne Fay [mailto:wayne...@gmail.com > > <javascript:;><javascript:;>] > > Sent: Tuesday, August 27, 2013 5:04 PM > > To: Maven Users List > > Subject: Re: artifact attached by plugin not appearing in subsequent > > plugins > > > > > Hi Wayne - that seems a very inefficient approach, having 5 or 6 > > > separate modules to manage to achieve a single assembly. The point > > > is that maven does have phases, goals, lifecycles - why not use > > > them? The MavenProject object already provides the > > > > Not saying this is ideal for all scenarios. Just saying it is one > > solution that works out of the box and it leaves the door open for > > customization you may need along the way. People here oftentimes say > > they > "just want to do X" > > and so we provide some advice. Then they come back a week later and > > say well actually they need variants of X for different clients, > > environments, architectures, etc so they share how they've been > > going down the path of profiles which most of us here believe is the > > wrong way to do things. I'm just trying to ensure you know TMTOWTDI > > (perl-ism). :) > > > > > ...I think dividing the construction of a single atomic component > > > into multiple modules because the plugins cannot be chained > > > together is more > > unappealing. > > > > I don't disagree. As I said, this is based on my assumption (perhaps > > wrong) that you have left a great many details out of your original > > query, and the next few emails will describe a monstrous beast you > > have created with profiles and binding plugins to various lifecycles > > etc in an effort to do "all the work" in a single project/module. > > ;-) > > > > > BTW I haven't touched Ant in at least 6 years, so I doubt I'm an > > > "Ant-oriented person". :-) > > > > Didn't mean you were necessarily Ant-oriented. I know you've > > released some Maven plugins lately. Thanks for your work in the > > Maven ecosystem! :) > > > > Wayne > > > > -------------------------------------------------------------------- > > - To unsubscribe, e-mail: > > users-unsubscr...@maven.apache.org<javascript:;> > > <javascript:;> For additional commands, e-mail: > > users-h...@maven.apache.org <javascript:;><javascript:;> > > > > > > > > > > -------------------------------------------------------------------- > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > <javascript:;> <javascript:;> For additional commands, e-mail: > > dev-h...@maven.apache.org <javascript:;> <javascript:;> > > > > > > -- > Sent from my phone > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > <javascript:;> For additional commands, e-mail: > dev-h...@maven.apache.org <javascript:;> > > -- Sent from my phone --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
