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>
<exclude>com.idfconnect.myproject:common-tools</exclude>
</excludes>
</artifactSet>
<minimizeJar>true</minimizeJar>
<shadedArtifactAttached>true</shadedArtifactAttached>
<shadedClassifierName>full</shadedClassifierName>
</configuration>
</execution>
</executions>
</plugin>
<!-- END SHADE -->
</plugins>
</build>
</profile>
</profiles>
So I'm getting a decent amount of mileage out of the notion of using
attachArtifact as a method of passing generated artifacts from one plugin to
the next.
So... now that I've modified maven-war-plugin and maven-shade-plugin to look at
attached artifacts, would anyone like me to submit the patches on JIRA? I
actually modified the shade plugin so you can run shade as a standalone goal,
e.g. explicitly specify the input artifact in the plugin configuration and mvn
shade away....
Also I'd like to suggest in any event that, for a future version of maven, it
add a "transient artifact" space to maven sessions to allow this communication
between plugins without actually writing the artifact to the local repository.
Looking forward to hearing your feedback. Thanks!
-Richard
-----Original Message-----
From: Wayne Fay [mailto:wayne...@gmail.com]
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
For additional commands, e-mail: users-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
