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] 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> > > <groupId>org.apache.maven.plugins</groupId> > > <artifactId>maven-shade-plugin</artifactId> > > <version>2.1-idfc1</version> > <executions> > <execution> > > <phase>package</phase> > > <goals> > > <goal>shade</goal> > > </goals> > > <configuration> > > <minimizeJar>true</minimizeJar> > > <shadedArtifactAttached>true</shadedArtifactAttached> > > <shadedClassifierName>full</shadedClassifierName> > > </configuration> > </execution> > </executions> > </plugin> > <!-- END SHADE --> > </plugins> > </build> > </profile> > > <!-- OBFUSCATION PROFILE --> > <profile> > <id>obfuscate</id> > <build> > <plugins> > <!-- BEGIN OBFUSCATE --> > <plugin> > > <groupId>com.idfconnect.devtools</groupId> > > <artifactId>idfc-proguard-maven-plugin</artifactId> > <version>1.0.0</version> > <executions> > <execution> > > <phase>package</phase> > > <goals> > > <goal>obfuscate</goal> > </goals> > </execution> > </executions> > <configuration> > > <shrink>false</shrink> > > <inputArtifacts> > > <inputArtifact>com.idfconnect.myproject:common-tools</inputArtifact> > </inputArtifacts> > > <libraryJarPaths> > > <libraryJarPath>${java.home}/lib/jsse.jar</libraryJarPath> > </libraryJarPaths> > </configuration> > <dependencies> > <dependency> > > <groupId>net.sf.proguard</groupId> > > <artifactId>proguard-base</artifactId> > > <version>4.9</version> > </dependency> > </dependencies> > </plugin> > <!-- END OBFUSCATE --> > > <!-- BEGIN SHADE --> > <plugin> > > <groupId>org.apache.maven.plugins</groupId> > > <artifactId>maven-shade-plugin</artifactId> > > <version>2.1-idfc1</version> > <executions> > <execution> > > <phase>package</phase> > > <goals> > > <goal>shade</goal> > > </goals> > > <configuration> > > <alternativeInputClassifier>small</alternativeInputClassifier> > > <artifactSet> > > <excludes> > > -Richard > > -----Original Message----- > From: Wayne Fay [mailto:wayne...@gmail.com <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:;> For additional commands, e-mail: > users-h...@maven.apache.org<javascript:;> > > > > > --------------------------------------------------------------------- > 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
