Packaging was originally meant to model a archive of some sort. The
POM packaging is stretching it because lifecycles are mapped to
packaging and we needed something different. I think this here too
might also be stretching it. I don't think an archive with API
signatures is a packaging. It's a secondary artifact like javadoc or
source jars. Except his jar has signatures in it.
On 2009-09-09, at 6:36 PM, Stephen Connolly wrote:
OK, this is related to animal-sniffer.
I have a new packaging type <packaging>signature</packaging>
This is designed to capture the signatures of an API, e.g. Java SE
1.4, Java
SE 1.5, etc.
But of course, it can do so much more, the way I have it set up you
can do
something like so:
<project>
<groupId>org.apache.maven</groupId>
<artifactId>maven-plugin-rt-signature</artifactId>
<version>2.0</version>
<packaging>signature</packaging>
<dependencies>
<dependency>
<groupId>org.codehaus.mojo.animal_sniffer.signatures</groupId>
<artifactId>javase</artifactId>
<version>1.4.0-1</version>
<type>signature</type>
</dependency>
<dependency>
<groupId>org.apache.maven</groupId>
<artifactId>maven-plugin-api</artifactId>
<version>2.0</version>
</dependency>
<dependency>
<groupId>org.apache.maven</groupId>
<artifactId>maven-core</artifactId>
<version>2.0</version>
</dependency>
<dependency>
<groupId>org.apache.maven</groupId>
<artifactId>maven-project</artifactId>
<version>2.0</version>
</dependency>
<dependency>
<!-- the rest of the maven 2.0 API -->
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>animal-sniffer-maven-plugin</artifactd>
<version>...</version>
<extensions>true</extensions>
</plugin>
</plugins>
</build>
</project>
and this will produce a set of signatures that is a combination of
all the
dependency jar files and the java SE 1.4 signatures.
You can then use that set of signatures to check your plugin against.
This can be quite flexible. I envision people creating signatures for
various different run time containers, certainly all the JavaSE
versions and
all the JavaEE versions... plus perhaps vendor specific signatures,
e.g.
WebSphere 6, etc
The question comes, where do we put the configuration about what
signature
to check.
Solution 1:
Put it in the plugin configuration. This is what I currently have,
e.g.
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>animal-sniffer-maven-plugin</artifactd>
<version>...</version>
<configuration>
<signature>
<groupId>org.apache.maven</groupId>
<artifactId>maven-plugin-rt-signature</artifactId>
<version>2.0</version>
</signature>
<configuration>
</plugin>
</plugins>
</build>
Pros:
* does not require adding the plugin with <extensions>true</
extensions> to
a build which is only running the check goal
* allows multiple executions to check multiple signatures
Cons:
* if the signatures are generated in a sibling module as part of a
multi-module build, you will need to either add the signature module
as a
dependency with <type>pom</type> and use release goals of "clean
install" as
opposed to "clean verify"
Solution 2:
Add it as a direct dependency with <type>signature</type>
Pros:
* automatically ensures that the build order is correct
* automatically works correctly with the "clean verify" as the release
goals
Cons:
* does not allow checking multiple signatures from the one profile
* "smells bad" according to Benjamin... i.e. this is not a 'real'
dependency... only the signatures of the 'real' dependencies.
Thoughts anyone?
-Stephen
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/SonatypeNexus
http://twitter.com/SonatypeM2E
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
