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
