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? -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] > >
