I wouldn't implement any of this like you are but that's me and you're
free to do what you like.
You should be able to put the lifecycle in an extension and then you
can use it as you like. I would be opposed to adding this packaging to
the core of Maven as we have done with things like WAR and EAR. Go nuts.
On 2009-09-09, at 7:46 PM, Stephen Connolly wrote:
2009/9/9 Jason van Zyl <jvan...@sonatype.com>
On 2009-09-09, at 6:56 PM, Stephen Connolly wrote:
2009/9/9 Jason van Zyl <jvan...@sonatype.com>
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.
I can see why attached artifacts are a good plan if you are starting
from an
environment which is defined completely by a JRE and your module.
the issues arrise with:
1. creating signatures for JRE's
2. creating signatures for JavaEE spec containers.
For these type of signatures I tend to favour a lifecycle, as
otherwise you
end up with a pom with packaging>pom< just to handle generating them.
Once I can get m-toolchains-p released, creating the jre signatures
is a tad
easier... but we still need modules to create the signatures.
also, I can see people using classifiers to qualify the signatures,
e.g.
sun java
ibm java
oracle java (jrockit)
apache harmony
etc.
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.
I was not aware of any eclipse framework to do what Kohsuke did with
animal-sniffer. Please send the details... though animal-sniffer
does what
is required at the moment, I'm just trying to tidy up the maven-
plugin to
make it easier for 3rd parties to build their own signatures, as
well as
make it easier for us to create signatures.
-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: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
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
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
