You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Stephen Connolly <st...@gmail.com> on 2009/09/09 18:36:17 UTC
When is a dependency a dependency?
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
Re: When is a dependency a dependency?
Posted by Jason van Zyl <jv...@sonatype.com>.
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 <jv...@sonatype.com>
>
>>
>> On 2009-09-09, at 6:56 PM, Stephen Connolly wrote:
>>
>> 2009/9/9 Jason van Zyl <jv...@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-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: When is a dependency a dependency?
Posted by Stephen Connolly <st...@gmail.com>.
2009/9/9 Jason van Zyl <jv...@sonatype.com>
>
> On 2009-09-09, at 6:56 PM, Stephen Connolly wrote:
>
> 2009/9/9 Jason van Zyl <jv...@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-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: When is a dependency a dependency?
Posted by Jason van Zyl <jv...@sonatype.com>.
On 2009-09-09, at 6:56 PM, Stephen Connolly wrote:
> 2009/9/9 Jason van Zyl <jv...@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.
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: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: When is a dependency a dependency?
Posted by Stephen Connolly <st...@gmail.com>.
2009/9/9 Jason van Zyl <jv...@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?
-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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: When is a dependency a dependency?
Posted by Jason van Zyl <jv...@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.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: When is a dependency a dependency?
Posted by Stephen Connolly <st...@gmail.com>.
08:18 -!- Irssi: Starting query in codehaus with brett
08:18 <SteveC> ok so this is animal-sniffer related
08:18 <SteveC> the primary reason I had for the lifecycle is JRE signatures
08:19 <brett> yup
08:19 <SteveC> first off
08:19 <SteveC> if I'm ditching the lifecycle
08:19 <SteveC> I remove the lifecycle mapping from components.xml
08:20 <SteveC> should I remove the artifactHandler config as well?
08:20 <brett> that's only needed if you are keeping the packaging / type
08:20 <SteveC> I have the artifact handler config at the moment to ensure
that
IncludesDependencies = true and isAddedToClasspath = false
08:21 <SteveC> I need to keep the artifact type as these are not jar files
08:21 <brett> that's unnecessary if you put it into a plugin dependency
instead
08:21 <brett> what type of file are they?
08:21 <SteveC> GZipOutputStream(ObjectOutputStream)
08:22 <SteveC> [this is the code Kohsuke wrote]
08:22 <SteveC> while I could change the format, it would mean that it was
not backwards
compatible with the signatures he generated
08:23 <SteveC> and OK, so I'm generating my own set of signatures in order
to get them
onto central
08:23 <brett> no, that makes sense
08:23 <brett> I see where you are going
08:23 <brett> you don't need the artifact handler if type = extension, which
will make it
easier for users
08:23 <brett> but the lifecycle still might make sense to default bind the
executions
08:24 <SteveC> hmmm
08:24 <SteveC> well packaging = extension
08:24 <SteveC> they're both .signature at the moment
08:25 <brett> so the default will work there
08:25 <SteveC> if you say so
08:25 <SteveC> ;-)
08:26 <SteveC> would you mind if i posted this transcript on the mailing
list?
08:27 <brett> that's fine
08:27 <SteveC> ok, so to summarise, you now are in favour of a lifecycle
mapping?
08:28 <SteveC> or does it still smell bad?
08:28 <SteveC> [benjamin suggested initially that it smelled bad, hence the
question on
the list]
08:29 <brett> well I think coming up with an arbitary format "just 'cause"
is what smells
bad :)
08:29 <brett> I think you can avoid it (basically follow the pattern of the
assembly
plugin)
08:29 <SteveC> ok, so the justification is backwards compat with Kohsuke's
orignal format
08:30 <brett> but if you feel like it makes it easier to work with (esp. if
there are
multiple bindings needed to do the work), then go for it
08:30 <brett> I don't think that's really relevant from what I understand
08:30 <brett> the artifact handler works as is
08:30 <brett> the lifecycle definition just allows you to preconfigure
certain bindings
08:30 <brett> is that right?
08:30 <SteveC> yep
08:30 <SteveC> and I only need one execution... so OK, no lifecycle
08:31 <SteveC> and no artifact handler => no component.xml
08:31 <SteveC> to generate sigs of JRE's you will need to use a
<packaging>pom</packaging> module
08:31 <brett> and no <extensions> in the plugin which is good for users
2009/9/10 Brett Porter <br...@apache.org>
> I agree with the subsequent discussion that I'm not sure why you need a
> lifecycle for it, but that doesn't seem relevant to your question:
>
> On 10/09/2009, at 2:36 AM, Stephen Connolly wrote:
>
> The question comes, where do we put the configuration about what signature
>> to check.
>>
>
> Solution 3, in a plugin dependency. It keeps it out of the project
> dependency list but retains proper ordering in recent versions of Maven.
> There are bugs with plugin dependencies if you have multiple instances of
> the plugin in a reactor in Maven 2, fixed in Maven 3 trunk.
>
> - Brett
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: When is a dependency a dependency?
Posted by Brett Porter <br...@apache.org>.
I agree with the subsequent discussion that I'm not sure why you need
a lifecycle for it, but that doesn't seem relevant to your question:
On 10/09/2009, at 2:36 AM, Stephen Connolly wrote:
> The question comes, where do we put the configuration about what
> signature
> to check.
Solution 3, in a plugin dependency. It keeps it out of the project
dependency list but retains proper ordering in recent versions of
Maven. There are bugs with plugin dependencies if you have multiple
instances of the plugin in a reactor in Maven 2, fixed in Maven 3 trunk.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org