Re: [vote] Invite Stephen Connolly to join Maven committers
+1 Emmanuel On Mon, Sep 7, 2009 at 1:24 AM, Arnaud HERITIER arnaud.herit...@exoplatform.com wrote: Hi all, I'd like to propose giving commit access to Stephen Connolly. He is already a committer @ Mojo for many monthes and did a great work on several plugins. He is the author of the very useful versions plugin. He is working on several others plugins like animal-sniffer. He's doing a job of quality (with unit and integration tests) and follows our best practices. He's participating on our mailing lists for a least 2 years. I helped him several time to apply some patches on our plugins and shared components. Now he would like to help on toolchains and adding its support in enforcer. I think we need more people as involved as Stephen has been. Please vote. 72h +1/+0/-1 Here is my +1. Cheers, Arnaud # Arnaud Héritier # Software Factory Manager # eXo Platform # http://www.exoplatform.com # http://blog.aheritier.net
Re: [vote] Invite Stephen Connolly to join Maven committers
+1 Vincent 2009/9/6 Arnaud HERITIER arnaud.herit...@exoplatform.com: Hi all, I'd like to propose giving commit access to Stephen Connolly. He is already a committer @ Mojo for many monthes and did a great work on several plugins. He is the author of the very useful versions plugin. He is working on several others plugins like animal-sniffer. He's doing a job of quality (with unit and integration tests) and follows our best practices. He's participating on our mailing lists for a least 2 years. I helped him several time to apply some patches on our plugins and shared components. Now he would like to help on toolchains and adding its support in enforcer. I think we need more people as involved as Stephen has been. Please vote. 72h +1/+0/-1 Here is my +1. Cheers, Arnaud # Arnaud Héritier # Software Factory Manager # eXo Platform # http://www.exoplatform.com # http://blog.aheritier.net - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [vote] Invite Stephen Connolly to join Maven committers
Stephen, If you're already an Apache committer just let me know what your id is, if fill out a CLA[1] and follow the instructions to send it in. When the CLA is processed we'll get your account setup. [1]: http://www.apache.org/licenses/ On 2009-09-09, at 12:45 PM, Vincent Siveton wrote: +1 Vincent 2009/9/6 Arnaud HERITIER arnaud.herit...@exoplatform.com: Hi all, I'd like to propose giving commit access to Stephen Connolly. He is already a committer @ Mojo for many monthes and did a great work on several plugins. He is the author of the very useful versions plugin. He is working on several others plugins like animal-sniffer. He's doing a job of quality (with unit and integration tests) and follows our best practices. He's participating on our mailing lists for a least 2 years. I helped him several time to apply some patches on our plugins and shared components. Now he would like to help on toolchains and adding its support in enforcer. I think we need more people as involved as Stephen has been. Please vote. 72h +1/+0/-1 Here is my +1. Cheers, Arnaud # Arnaud Héritier # Software Factory Manager # eXo Platform # http://www.exoplatform.com # http://blog.aheritier.net - 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
Re: svn commit: r812962 - /maven/plugins/trunk/maven-project-info-reports-plugin/pom.xml
vsive...@apache.org wrote: Author: vsiveton Date: Wed Sep 9 13:52:40 2009 New Revision: 812962 URL: http://svn.apache.org/viewvc?rev=812962view=rev Log: o switch to 2.1 maven prerequisite Why? Modified: maven/plugins/trunk/maven-project-info-reports-plugin/pom.xml Modified: maven/plugins/trunk/maven-project-info-reports-plugin/pom.xml URL: http://svn.apache.org/viewvc/maven/plugins/trunk/maven-project-info-reports-plugin/pom.xml?rev=812962r1=812961r2=812962view=diff == --- maven/plugins/trunk/maven-project-info-reports-plugin/pom.xml (original) +++ maven/plugins/trunk/maven-project-info-reports-plugin/pom.xml Wed Sep 9 13:52:40 2009 @@ -70,7 +70,7 @@ properties doxiaVersion1.1.2-SNAPSHOT/doxiaVersion doxia-sitetoolsVersion1.1.2-SNAPSHOT/doxia-sitetoolsVersion -mavenVersion2.0.6/mavenVersion +mavenVersion2.1.0/mavenVersion wagonVersion1.0-beta-3/wagonVersion scmVersion1.1/scmVersion sitePluginVersion2.0.1/sitePluginVersion -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
When is a dependency a dependency?
OK, this is related to animal-sniffer. I have a new packaging type packagingsignature/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 groupIdorg.apache.maven/groupId artifactIdmaven-plugin-rt-signature/artifactId version2.0/version packagingsignature/packaging dependencies dependency groupIdorg.codehaus.mojo.animal_sniffer.signatures/groupId artifactIdjavase/artifactId version1.4.0-1/version typesignature/type /dependency dependency groupIdorg.apache.maven/groupId artifactIdmaven-plugin-api/artifactId version2.0/version /dependency dependency groupIdorg.apache.maven/groupId artifactIdmaven-core/artifactId version2.0/version /dependency dependency groupIdorg.apache.maven/groupId artifactIdmaven-project/artifactId version2.0/version /dependency dependency !-- the rest of the maven 2.0 API -- /dependency /dependencies build plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdanimal-sniffer-maven-plugin/artifactd version.../version extensionstrue/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 groupIdorg.codehaus.mojo/groupId artifactIdanimal-sniffer-maven-plugin/artifactd version.../version configuration signature groupIdorg.apache.maven/groupId artifactIdmaven-plugin-rt-signature/artifactId version2.0/version /signature configuration /plugin /plugins /build Pros: * does not require adding the plugin with extensionstrue/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 typepom/type and use release goals of clean install as opposed to clean verify Solution 2: Add it as a direct dependency with typesignature/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?
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 packagingsignature/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 groupIdorg.apache.maven/groupId artifactIdmaven-plugin-rt-signature/artifactId version2.0/version packagingsignature/packaging dependencies dependency groupIdorg.codehaus.mojo.animal_sniffer.signatures/groupId artifactIdjavase/artifactId version1.4.0-1/version typesignature/type /dependency dependency groupIdorg.apache.maven/groupId artifactIdmaven-plugin-api/artifactId version2.0/version /dependency dependency groupIdorg.apache.maven/groupId artifactIdmaven-core/artifactId version2.0/version /dependency dependency groupIdorg.apache.maven/groupId artifactIdmaven-project/artifactId version2.0/version /dependency dependency !-- the rest of the maven 2.0 API -- /dependency /dependencies build plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdanimal-sniffer-maven-plugin/artifactd version.../version extensionstrue/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 groupIdorg.codehaus.mojo/groupId artifactIdanimal-sniffer-maven-plugin/artifactd version.../version configuration signature groupIdorg.apache.maven/groupId artifactIdmaven-plugin-rt-signature/artifactId version2.0/version /signature configuration /plugin /plugins /build Pros: * does not require adding the plugin with extensionstrue/ 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 typepom/type and use release goals of clean install as opposed to clean verify Solution 2: Add it as a direct dependency with typesignature/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
Re: When is a dependency a dependency?
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? -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 packagingsignature/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 groupIdorg.apache.maven/groupId artifactIdmaven-plugin-rt-signature/artifactId version2.0/version packagingsignature/packaging dependencies dependency groupIdorg.codehaus.mojo.animal_sniffer.signatures/groupId artifactIdjavase/artifactId version1.4.0-1/version typesignature/type /dependency dependency groupIdorg.apache.maven/groupId artifactIdmaven-plugin-api/artifactId version2.0/version /dependency dependency groupIdorg.apache.maven/groupId artifactIdmaven-core/artifactId version2.0/version /dependency dependency groupIdorg.apache.maven/groupId artifactIdmaven-project/artifactId version2.0/version /dependency dependency !-- the rest of the maven 2.0 API -- /dependency /dependencies build plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdanimal-sniffer-maven-plugin/artifactd version.../version extensionstrue/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 groupIdorg.codehaus.mojo/groupId artifactIdanimal-sniffer-maven-plugin/artifactd version.../version configuration signature groupIdorg.apache.maven/groupId artifactIdmaven-plugin-rt-signature/artifactId version2.0/version /signature configuration /plugin /plugins /build Pros: * does not require adding the plugin with extensionstrue/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 typepom/type and use release goals of clean install as opposed to clean verify Solution 2: Add it as a direct dependency with typesignature/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
Re: When is a dependency a dependency?
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. 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 packagingsignature/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 groupIdorg.apache.maven/groupId artifactIdmaven-plugin-rt-signature/artifactId version2.0/version packagingsignature/packaging dependencies dependency groupIdorg.codehaus.mojo.animal_sniffer.signatures/groupId artifactIdjavase/artifactId version1.4.0-1/version typesignature/type /dependency dependency groupIdorg.apache.maven/groupId artifactIdmaven-plugin-api/artifactId version2.0/version /dependency dependency groupIdorg.apache.maven/groupId artifactIdmaven-core/artifactId version2.0/version /dependency dependency groupIdorg.apache.maven/groupId artifactIdmaven-project/artifactId version2.0/version /dependency dependency !-- the rest of the maven 2.0 API -- /dependency /dependencies build plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdanimal-sniffer-maven-plugin/artifactd version.../version extensionstrue/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 groupIdorg.codehaus.mojo/groupId artifactIdanimal-sniffer-maven-plugin/artifactd version.../version configuration signature groupIdorg.apache.maven/groupId artifactIdmaven-plugin-rt-signature/artifactId version2.0/version /signature configuration /plugin /plugins /build Pros: * does not require adding the plugin with extensionstrue/ 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 typepom/type and use release goals of clean install as opposed to clean verify Solution 2: Add it as a direct dependency with typesignature/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,
Re: When is a dependency a dependency?
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 packagingpom 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 packagingsignature/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 groupIdorg.apache.maven/groupId artifactIdmaven-plugin-rt-signature/artifactId version2.0/version packagingsignature/packaging dependencies dependency groupIdorg.codehaus.mojo.animal_sniffer.signatures/groupId artifactIdjavase/artifactId version1.4.0-1/version typesignature/type /dependency dependency groupIdorg.apache.maven/groupId artifactIdmaven-plugin-api/artifactId version2.0/version /dependency dependency groupIdorg.apache.maven/groupId artifactIdmaven-core/artifactId version2.0/version /dependency dependency groupIdorg.apache.maven/groupId artifactIdmaven-project/artifactId version2.0/version /dependency dependency !-- the rest of the maven 2.0 API -- /dependency /dependencies build plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdanimal-sniffer-maven-plugin/artifactd version.../version extensionstrue/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 groupIdorg.codehaus.mojo/groupId artifactIdanimal-sniffer-maven-plugin/artifactd version.../version configuration signature groupIdorg.apache.maven/groupId artifactIdmaven-plugin-rt-signature/artifactId version2.0/version /signature configuration /plugin /plugins /build Pros: * does not require adding the plugin with extensionstrue/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
Re: When is a dependency a dependency?
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 packagingpom 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 packagingsignature/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 groupIdorg.apache.maven/groupId artifactIdmaven-plugin-rt-signature/artifactId version2.0/version packagingsignature/packaging dependencies dependency groupIdorg.codehaus.mojo.animal_sniffer.signatures/groupId artifactIdjavase/artifactId version1.4.0-1/version typesignature/type /dependency dependency groupIdorg.apache.maven/groupId artifactIdmaven-plugin-api/artifactId version2.0/version /dependency dependency groupIdorg.apache.maven/groupId artifactIdmaven-core/artifactId version2.0/version /dependency dependency groupIdorg.apache.maven/groupId artifactIdmaven-project/artifactId version2.0/version /dependency dependency !-- the rest of the maven 2.0 API -- /dependency /dependencies build plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdanimal-sniffer-maven-plugin/artifactd version.../version extensionstrue/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 groupIdorg.codehaus.mojo/groupId artifactIdanimal-sniffer-maven-plugin/artifactd version.../version configuration signature groupIdorg.apache.maven/groupId artifactIdmaven-plugin-rt-signature/artifactId version2.0/version /signature configuration /plugin /plugins /build Pros: * does not require adding the plugin with
Re: When is a dependency a dependency?
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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
