On 2009-09-09, at 6:56 PM, Stephen Connolly wrote:
2009/9/9 Jason van Zyl <[email protected]>
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.
I presume you meant "Except this object-stream.gz has signatures in
it" and
not "Except his jar has signatures in it"?
Also, are you suggesting not having a "signature" lifecycle at all?
I don't see why you need to bind it to a lifecycle, and I would
honestly build out a tool chain for operating on all of these things
independently. The collection and analysis of signatures can all be
handled without creating a lifecycle. I really don't see this as a
good fit for another packaging.
You also know that Eclipse has built out an entire framework for this
that is quite extensive. I'll find the links if you're interested but
it's been there for a couple years. It's for bundles but that's just a
jar with a manifest so it could be leveraged.
-Stephen
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: [email protected]
For additional commands, e-mail: [email protected]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/SonatypeNexus
http://twitter.com/SonatypeM2E
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
