2009/9/9 Jason van Zyl <[email protected]> > > 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. > > 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: [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] > >
