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
