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:[email protected] <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: [email protected] <javascript:;>
> For additional commands, e-mail: [email protected]<javascript:;>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected] <javascript:;>
> For additional commands, e-mail: [email protected] <javascript:;>
>
>
--
Sent from my phone
