Re: [VOTE] release versions-maven-plugin 1.0-alpha-1
Le mardi 02 septembre 2008, Dennis Lundberg a écrit : > After trying this plugin on some more projects I have found that > NumericVersionComparator seems to do a better overall job than > MavenVersionComparator. See hsqldb in the example below for an odd > result using the default comparisonMethod. > > [INFO] The following dependency updates are available: > [INFO] commons-lang:commons-lang .. 2.1 -> 2.4 > [INFO] hsqldb:hsqldb 1.8.0.1 -> 1.7.2-rc1 > > Any chance of using "numeric" as the default method instead? there is also ComparableVersion that has been integrated in maven-artifact 3.0-SNAPSHOT see http://svn.apache.org/viewvc/maven/artifact/trunk/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java and http://docs.codehaus.org/display/MAVEN/Versioning Regards Hervé - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT] [VOTE] release versions-maven-plugin 1.0-alpha-1
On Tue, Sep 2, 2008 at 12:07 AM, Stephen Connolly < [EMAIL PROTECTED]> wrote: > Vote will be open for 72 hours and will conclude via lazy consensus. > This vote has passed: +1: Benjamin V. 0: Benjamin B. Thanks for reviewing and helpful comments go to: Benjamin B, Dennis and Nicolas. I will finish the release soon.
Re: [VOTE] release versions-maven-plugin 1.0-alpha-1
OK, that (other plugins using it as the default) is a valid case, I have changed the default to false On Wed, Sep 3, 2008 at 8:31 AM, nicolas de loof <[EMAIL PROTECTED]> wrote: > I also would prefer allowSnapshots to be set to false by default, to match > the release plugin allowSnapshots parameter and the enforcer plugin default > rules > Nicolas > > 2008/9/3 Stephen Connolly <[EMAIL PROTECTED]> > >> On Tue, Sep 2, 2008 at 11:08 PM, Dennis Lundberg <[EMAIL PROTECTED]> >> wrote: >> > Stephen Connolly wrote: >> >> On Tue, Sep 2, 2008 at 9:40 PM, Dennis Lundberg <[EMAIL PROTECTED]> >> wrote: >> >>> Hi Stephen >> >>> >> >>> Great work on this plugin! This is a plugin that I plan to use >> extensively. >> >>> >> >>> I've read through the docs, which there are plenty of. Always a good >> >>> sign :-) There were however a couple of typos and broken links in >> there, >> >>> which I took the liberty of fixing in SVN. I also updated to >> mojo-parent 18. >> >>> >> >> >> >> Thanks, I forgot I had to switch back to mojo-parent 18 >> >> >> >>> After playing around with the plugin a bit I found the results somewhat >> >>> confusing, so I started to read the goal parameter docs. There I found >> >>> the source of my confusion: the allowSnapshots parameter has true as >> >>> default value. In my opinion this should be set to false as default. >> >>> Using snapshots is something that should be avoided, if possible. >> >>> Showing snapshot versions by default therefor works against best >> >>> practices and might lure users to the dark side. >> >>> >> >> >> >> I'm 50:50 on this. >> >> >> >> I use it to switch all the suit of projects onto SNAPSHOT versions >> >> while I'm working on them. When doing a release the release will be >> >> the newest version in the repo so puching back to SCM is fine in that >> >> case. >> >> >> >> However I can see the other side. >> > >> > There are apparently different use cases for this goal. Here's my use >> > case. One step in our release process is to check to see if there are >> > any dependencies that should be updated. When doing that I don't want >> > any snapshots, because the release is near. >> >> just add -DallowSnapshots=false >> > >> >> >> >>> I'd like to move the includeProperties, excludeProperties and linkItems >> >>> parameters from the Abstract Mojo to UpdatePropertiesMojo, because they >> >>> are only used there. Also the parentVersion parameter should be moved >> to >> >>> UpdateParentMojo. Having them in the Abstract Mojo makes them show up >> as >> >>> parameters in the auto generated docs for every Mojo, see [1]. >> >>> >> >> >> >> Fire ahead, when I moved them there I did not have the display goals. >> > >> > I will. >> > >> >>> The comparisonMethod parameter is currently only used in >> >>> DisplayDependencyUpdatesMojo. Shouldn't it be used in >> >>> DisplayPluginUpdatesMojo as well? >> >> >> >> OK, here is my logic: >> >> >> >> Maven plugins _should_ be versioned using the Maven version rules, >> >> i.e. Major.Minor.Update-Build >> >> >> >> Dependencies will be versioned using company rules (in our case 5 >> digits) >> >> >> >> So you don't need the comparison method for plugins. >> >> >> >> What do you think? >> > >> > What about plugins developed internally by companies, that are versioned >> > using the company rules? >> > >> >> >> >>> If not, it can be moved from the Abstract Mojo to >> >>> DisplayDependencyUpdatesMojo. >> >> >> >> Go ahead >> >>> Finally the auto generated docs would benefit from using >> "default-value" >> >>> in the @parameter annotations. This automatically inserts the default >> >>> values into the docs. >> >>> >> >> >> >> If you don't mind doing that please >> > >> > OK >> > >> >>> If you want me to, I can have a go at making these changes. >> >>> >> >> >> >> Please do >> >>> [1] >> >>> >> http://mojo.codehaus.org/versions-maven-plugin/display-dependency-updates-mojo.html >> >>> >> >>> Stephen Connolly wrote: >> Folks, I've been working on the versions-maven-plugin and I think it's >> ready to cut the first alpha release. >> >> The major changes in this release are >> - Fixed MOJO-1209 (required a rewrite of the display-plugin-updates >> goal) >> >> Known issues >> >> - MOJO-1210 display-plugin-updates does not include lifecycle plugins >> that are not defined in the pom >> - MOJO-1211 display-plugin-updates does not identify the plugin >> version as not being provided when derived from the super-pom >> >> Both of these issues will require a bit of work and I'd rather get an >> alpha release out before trying to fix them. >> >> The new site has just been deployed here: >> http://mojo.codehaus.org/versions-maven-plugin >> >> Snapshot have been published on >> >> http://snapshots.repository.codehaus.org/org/codehaus/mojo/versions-maven-plugin >> >> [+1] release it >> [0] don't care >> [-1] don't release ! >> >
Re: [VOTE] release versions-maven-plugin 1.0-alpha-1
I also would prefer allowSnapshots to be set to false by default, to match the release plugin allowSnapshots parameter and the enforcer plugin default rules Nicolas 2008/9/3 Stephen Connolly <[EMAIL PROTECTED]> > On Tue, Sep 2, 2008 at 11:08 PM, Dennis Lundberg <[EMAIL PROTECTED]> > wrote: > > Stephen Connolly wrote: > >> On Tue, Sep 2, 2008 at 9:40 PM, Dennis Lundberg <[EMAIL PROTECTED]> > wrote: > >>> Hi Stephen > >>> > >>> Great work on this plugin! This is a plugin that I plan to use > extensively. > >>> > >>> I've read through the docs, which there are plenty of. Always a good > >>> sign :-) There were however a couple of typos and broken links in > there, > >>> which I took the liberty of fixing in SVN. I also updated to > mojo-parent 18. > >>> > >> > >> Thanks, I forgot I had to switch back to mojo-parent 18 > >> > >>> After playing around with the plugin a bit I found the results somewhat > >>> confusing, so I started to read the goal parameter docs. There I found > >>> the source of my confusion: the allowSnapshots parameter has true as > >>> default value. In my opinion this should be set to false as default. > >>> Using snapshots is something that should be avoided, if possible. > >>> Showing snapshot versions by default therefor works against best > >>> practices and might lure users to the dark side. > >>> > >> > >> I'm 50:50 on this. > >> > >> I use it to switch all the suit of projects onto SNAPSHOT versions > >> while I'm working on them. When doing a release the release will be > >> the newest version in the repo so puching back to SCM is fine in that > >> case. > >> > >> However I can see the other side. > > > > There are apparently different use cases for this goal. Here's my use > > case. One step in our release process is to check to see if there are > > any dependencies that should be updated. When doing that I don't want > > any snapshots, because the release is near. > > just add -DallowSnapshots=false > > > >> > >>> I'd like to move the includeProperties, excludeProperties and linkItems > >>> parameters from the Abstract Mojo to UpdatePropertiesMojo, because they > >>> are only used there. Also the parentVersion parameter should be moved > to > >>> UpdateParentMojo. Having them in the Abstract Mojo makes them show up > as > >>> parameters in the auto generated docs for every Mojo, see [1]. > >>> > >> > >> Fire ahead, when I moved them there I did not have the display goals. > > > > I will. > > > >>> The comparisonMethod parameter is currently only used in > >>> DisplayDependencyUpdatesMojo. Shouldn't it be used in > >>> DisplayPluginUpdatesMojo as well? > >> > >> OK, here is my logic: > >> > >> Maven plugins _should_ be versioned using the Maven version rules, > >> i.e. Major.Minor.Update-Build > >> > >> Dependencies will be versioned using company rules (in our case 5 > digits) > >> > >> So you don't need the comparison method for plugins. > >> > >> What do you think? > > > > What about plugins developed internally by companies, that are versioned > > using the company rules? > > > >> > >>> If not, it can be moved from the Abstract Mojo to > >>> DisplayDependencyUpdatesMojo. > >> > >> Go ahead > >>> Finally the auto generated docs would benefit from using > "default-value" > >>> in the @parameter annotations. This automatically inserts the default > >>> values into the docs. > >>> > >> > >> If you don't mind doing that please > > > > OK > > > >>> If you want me to, I can have a go at making these changes. > >>> > >> > >> Please do > >>> [1] > >>> > http://mojo.codehaus.org/versions-maven-plugin/display-dependency-updates-mojo.html > >>> > >>> Stephen Connolly wrote: > Folks, I've been working on the versions-maven-plugin and I think it's > ready to cut the first alpha release. > > The major changes in this release are > - Fixed MOJO-1209 (required a rewrite of the display-plugin-updates > goal) > > Known issues > > - MOJO-1210 display-plugin-updates does not include lifecycle plugins > that are not defined in the pom > - MOJO-1211 display-plugin-updates does not identify the plugin > version as not being provided when derived from the super-pom > > Both of these issues will require a bit of work and I'd rather get an > alpha release out before trying to fix them. > > The new site has just been deployed here: > http://mojo.codehaus.org/versions-maven-plugin > > Snapshot have been published on > > http://snapshots.repository.codehaus.org/org/codehaus/mojo/versions-maven-plugin > > [+1] release it > [0] don't care > [-1] don't release ! > > Vote will be open for 72 hours and will conclude via lazy consensus. > > Please vote :-) > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > >>> > >
Re: [VOTE] release versions-maven-plugin 1.0-alpha-1
Consider this... if the repo versions available are 1.0, 1.1, 1.2-SNAPSHOT does [0,) match 1.2-SNAPSHOT? AFAIK, yes what is the newest version? AFAIK 1.2-SNAPSHOT AFAIK maven's rules will allow 1.2-SNAPSHOT to match 1.0 as without the [] that is an advisory version number only. This was my logic in picking allowSnaphots default to true -Stephen P.S. don;t forget to add yourself to the developers section On Tue, Sep 2, 2008 at 11:52 PM, Stephen Connolly <[EMAIL PROTECTED]> wrote: > only if they have snapshots deployed. > > In our environment we don't deploy snapshots other than to the local > repository... thus I only see SNAPSHOTs if I did a local build of > those snapshots (which is why I want the snapshots pulled in. > > An alternative is to split each goal into two goals (one that includes > snapshots and one that excludes them) > > On Tue, Sep 2, 2008 at 11:46 PM, Dennis Lundberg <[EMAIL PROTECTED]> wrote: >> Stephen Connolly wrote: >>> On Tue, Sep 2, 2008 at 11:08 PM, Dennis Lundberg <[EMAIL PROTECTED]> wrote: Stephen Connolly wrote: > On Tue, Sep 2, 2008 at 9:40 PM, Dennis Lundberg <[EMAIL PROTECTED]> wrote: >> Hi Stephen >> >> Great work on this plugin! This is a plugin that I plan to use >> extensively. >> >> I've read through the docs, which there are plenty of. Always a good >> sign :-) There were however a couple of typos and broken links in there, >> which I took the liberty of fixing in SVN. I also updated to mojo-parent >> 18. >> > Thanks, I forgot I had to switch back to mojo-parent 18 > >> After playing around with the plugin a bit I found the results somewhat >> confusing, so I started to read the goal parameter docs. There I found >> the source of my confusion: the allowSnapshots parameter has true as >> default value. In my opinion this should be set to false as default. >> Using snapshots is something that should be avoided, if possible. >> Showing snapshot versions by default therefor works against best >> practices and might lure users to the dark side. >> > I'm 50:50 on this. > > I use it to switch all the suit of projects onto SNAPSHOT versions > while I'm working on them. When doing a release the release will be > the newest version in the repo so puching back to SCM is fine in that > case. > > However I can see the other side. There are apparently different use cases for this goal. Here's my use case. One step in our release process is to check to see if there are any dependencies that should be updated. When doing that I don't want any snapshots, because the release is near. >>> >>> just add -DallowSnapshots=false >> >> Yes, for me that's not a problem. >> >> My main concern is the signals we will be sending to the users, telling >> them to update to snapshot versions. >> >> >> >> >> -- >> Dennis Lundberg >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] release versions-maven-plugin 1.0-alpha-1
only if they have snapshots deployed. In our environment we don't deploy snapshots other than to the local repository... thus I only see SNAPSHOTs if I did a local build of those snapshots (which is why I want the snapshots pulled in. An alternative is to split each goal into two goals (one that includes snapshots and one that excludes them) On Tue, Sep 2, 2008 at 11:46 PM, Dennis Lundberg <[EMAIL PROTECTED]> wrote: > Stephen Connolly wrote: >> On Tue, Sep 2, 2008 at 11:08 PM, Dennis Lundberg <[EMAIL PROTECTED]> wrote: >>> Stephen Connolly wrote: On Tue, Sep 2, 2008 at 9:40 PM, Dennis Lundberg <[EMAIL PROTECTED]> wrote: > Hi Stephen > > Great work on this plugin! This is a plugin that I plan to use > extensively. > > I've read through the docs, which there are plenty of. Always a good > sign :-) There were however a couple of typos and broken links in there, > which I took the liberty of fixing in SVN. I also updated to mojo-parent > 18. > Thanks, I forgot I had to switch back to mojo-parent 18 > After playing around with the plugin a bit I found the results somewhat > confusing, so I started to read the goal parameter docs. There I found > the source of my confusion: the allowSnapshots parameter has true as > default value. In my opinion this should be set to false as default. > Using snapshots is something that should be avoided, if possible. > Showing snapshot versions by default therefor works against best > practices and might lure users to the dark side. > I'm 50:50 on this. I use it to switch all the suit of projects onto SNAPSHOT versions while I'm working on them. When doing a release the release will be the newest version in the repo so puching back to SCM is fine in that case. However I can see the other side. >>> There are apparently different use cases for this goal. Here's my use >>> case. One step in our release process is to check to see if there are >>> any dependencies that should be updated. When doing that I don't want >>> any snapshots, because the release is near. >> >> just add -DallowSnapshots=false > > Yes, for me that's not a problem. > > My main concern is the signals we will be sending to the users, telling > them to update to snapshot versions. > > > > > -- > Dennis Lundberg > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] release versions-maven-plugin 1.0-alpha-1
Stephen Connolly wrote: > On Tue, Sep 2, 2008 at 11:08 PM, Dennis Lundberg <[EMAIL PROTECTED]> wrote: >> Stephen Connolly wrote: >>> On Tue, Sep 2, 2008 at 9:40 PM, Dennis Lundberg <[EMAIL PROTECTED]> wrote: Hi Stephen Great work on this plugin! This is a plugin that I plan to use extensively. I've read through the docs, which there are plenty of. Always a good sign :-) There were however a couple of typos and broken links in there, which I took the liberty of fixing in SVN. I also updated to mojo-parent 18. >>> Thanks, I forgot I had to switch back to mojo-parent 18 >>> After playing around with the plugin a bit I found the results somewhat confusing, so I started to read the goal parameter docs. There I found the source of my confusion: the allowSnapshots parameter has true as default value. In my opinion this should be set to false as default. Using snapshots is something that should be avoided, if possible. Showing snapshot versions by default therefor works against best practices and might lure users to the dark side. >>> I'm 50:50 on this. >>> >>> I use it to switch all the suit of projects onto SNAPSHOT versions >>> while I'm working on them. When doing a release the release will be >>> the newest version in the repo so puching back to SCM is fine in that >>> case. >>> >>> However I can see the other side. >> There are apparently different use cases for this goal. Here's my use >> case. One step in our release process is to check to see if there are >> any dependencies that should be updated. When doing that I don't want >> any snapshots, because the release is near. > > just add -DallowSnapshots=false Yes, for me that's not a problem. My main concern is the signals we will be sending to the users, telling them to update to snapshot versions. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] release versions-maven-plugin 1.0-alpha-1
On Tue, Sep 2, 2008 at 11:08 PM, Dennis Lundberg <[EMAIL PROTECTED]> wrote: > Stephen Connolly wrote: >> On Tue, Sep 2, 2008 at 9:40 PM, Dennis Lundberg <[EMAIL PROTECTED]> wrote: >>> Hi Stephen >>> >>> Great work on this plugin! This is a plugin that I plan to use extensively. >>> >>> I've read through the docs, which there are plenty of. Always a good >>> sign :-) There were however a couple of typos and broken links in there, >>> which I took the liberty of fixing in SVN. I also updated to mojo-parent 18. >>> >> >> Thanks, I forgot I had to switch back to mojo-parent 18 >> >>> After playing around with the plugin a bit I found the results somewhat >>> confusing, so I started to read the goal parameter docs. There I found >>> the source of my confusion: the allowSnapshots parameter has true as >>> default value. In my opinion this should be set to false as default. >>> Using snapshots is something that should be avoided, if possible. >>> Showing snapshot versions by default therefor works against best >>> practices and might lure users to the dark side. >>> >> >> I'm 50:50 on this. >> >> I use it to switch all the suit of projects onto SNAPSHOT versions >> while I'm working on them. When doing a release the release will be >> the newest version in the repo so puching back to SCM is fine in that >> case. >> >> However I can see the other side. > > There are apparently different use cases for this goal. Here's my use > case. One step in our release process is to check to see if there are > any dependencies that should be updated. When doing that I don't want > any snapshots, because the release is near. just add -DallowSnapshots=false > >> >>> I'd like to move the includeProperties, excludeProperties and linkItems >>> parameters from the Abstract Mojo to UpdatePropertiesMojo, because they >>> are only used there. Also the parentVersion parameter should be moved to >>> UpdateParentMojo. Having them in the Abstract Mojo makes them show up as >>> parameters in the auto generated docs for every Mojo, see [1]. >>> >> >> Fire ahead, when I moved them there I did not have the display goals. > > I will. > >>> The comparisonMethod parameter is currently only used in >>> DisplayDependencyUpdatesMojo. Shouldn't it be used in >>> DisplayPluginUpdatesMojo as well? >> >> OK, here is my logic: >> >> Maven plugins _should_ be versioned using the Maven version rules, >> i.e. Major.Minor.Update-Build >> >> Dependencies will be versioned using company rules (in our case 5 digits) >> >> So you don't need the comparison method for plugins. >> >> What do you think? > > What about plugins developed internally by companies, that are versioned > using the company rules? > >> >>> If not, it can be moved from the Abstract Mojo to >>> DisplayDependencyUpdatesMojo. >> >> Go ahead >>> Finally the auto generated docs would benefit from using "default-value" >>> in the @parameter annotations. This automatically inserts the default >>> values into the docs. >>> >> >> If you don't mind doing that please > > OK > >>> If you want me to, I can have a go at making these changes. >>> >> >> Please do >>> [1] >>> http://mojo.codehaus.org/versions-maven-plugin/display-dependency-updates-mojo.html >>> >>> Stephen Connolly wrote: Folks, I've been working on the versions-maven-plugin and I think it's ready to cut the first alpha release. The major changes in this release are - Fixed MOJO-1209 (required a rewrite of the display-plugin-updates goal) Known issues - MOJO-1210 display-plugin-updates does not include lifecycle plugins that are not defined in the pom - MOJO-1211 display-plugin-updates does not identify the plugin version as not being provided when derived from the super-pom Both of these issues will require a bit of work and I'd rather get an alpha release out before trying to fix them. The new site has just been deployed here: http://mojo.codehaus.org/versions-maven-plugin Snapshot have been published on http://snapshots.repository.codehaus.org/org/codehaus/mojo/versions-maven-plugin [+1] release it [0] don't care [-1] don't release ! Vote will be open for 72 hours and will conclude via lazy consensus. Please vote :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> -- >>> Dennis Lundberg >>> >>> - >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > -- > Dennis Lundberg > > ---
Re: [VOTE] release versions-maven-plugin 1.0-alpha-1
Stephen Connolly wrote: > On Tue, Sep 2, 2008 at 9:40 PM, Dennis Lundberg <[EMAIL PROTECTED]> wrote: >> Hi Stephen >> >> Great work on this plugin! This is a plugin that I plan to use extensively. >> >> I've read through the docs, which there are plenty of. Always a good >> sign :-) There were however a couple of typos and broken links in there, >> which I took the liberty of fixing in SVN. I also updated to mojo-parent 18. >> > > Thanks, I forgot I had to switch back to mojo-parent 18 > >> After playing around with the plugin a bit I found the results somewhat >> confusing, so I started to read the goal parameter docs. There I found >> the source of my confusion: the allowSnapshots parameter has true as >> default value. In my opinion this should be set to false as default. >> Using snapshots is something that should be avoided, if possible. >> Showing snapshot versions by default therefor works against best >> practices and might lure users to the dark side. >> > > I'm 50:50 on this. > > I use it to switch all the suit of projects onto SNAPSHOT versions > while I'm working on them. When doing a release the release will be > the newest version in the repo so puching back to SCM is fine in that > case. > > However I can see the other side. There are apparently different use cases for this goal. Here's my use case. One step in our release process is to check to see if there are any dependencies that should be updated. When doing that I don't want any snapshots, because the release is near. > >> I'd like to move the includeProperties, excludeProperties and linkItems >> parameters from the Abstract Mojo to UpdatePropertiesMojo, because they >> are only used there. Also the parentVersion parameter should be moved to >> UpdateParentMojo. Having them in the Abstract Mojo makes them show up as >> parameters in the auto generated docs for every Mojo, see [1]. >> > > Fire ahead, when I moved them there I did not have the display goals. I will. >> The comparisonMethod parameter is currently only used in >> DisplayDependencyUpdatesMojo. Shouldn't it be used in >> DisplayPluginUpdatesMojo as well? > > OK, here is my logic: > > Maven plugins _should_ be versioned using the Maven version rules, > i.e. Major.Minor.Update-Build > > Dependencies will be versioned using company rules (in our case 5 digits) > > So you don't need the comparison method for plugins. > > What do you think? What about plugins developed internally by companies, that are versioned using the company rules? > >> If not, it can be moved from the Abstract Mojo to >> DisplayDependencyUpdatesMojo. > > Go ahead >> Finally the auto generated docs would benefit from using "default-value" >> in the @parameter annotations. This automatically inserts the default >> values into the docs. >> > > If you don't mind doing that please OK >> If you want me to, I can have a go at making these changes. >> > > Please do >> [1] >> http://mojo.codehaus.org/versions-maven-plugin/display-dependency-updates-mojo.html >> >> Stephen Connolly wrote: >>> Folks, I've been working on the versions-maven-plugin and I think it's >>> ready to cut the first alpha release. >>> >>> The major changes in this release are >>> - Fixed MOJO-1209 (required a rewrite of the display-plugin-updates goal) >>> >>> Known issues >>> >>> - MOJO-1210 display-plugin-updates does not include lifecycle plugins >>> that are not defined in the pom >>> - MOJO-1211 display-plugin-updates does not identify the plugin >>> version as not being provided when derived from the super-pom >>> >>> Both of these issues will require a bit of work and I'd rather get an >>> alpha release out before trying to fix them. >>> >>> The new site has just been deployed here: >>> http://mojo.codehaus.org/versions-maven-plugin >>> >>> Snapshot have been published on >>> http://snapshots.repository.codehaus.org/org/codehaus/mojo/versions-maven-plugin >>> >>> [+1] release it >>> [0] don't care >>> [-1] don't release ! >>> >>> Vote will be open for 72 hours and will conclude via lazy consensus. >>> >>> Please vote :-) >>> >>> - >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> -- >> Dennis Lundberg >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] release versions-maven-plugin 1.0-alpha-1
On Tue, Sep 2, 2008 at 9:54 PM, Dennis Lundberg <[EMAIL PROTECTED]> wrote: > After trying this plugin on some more projects I have found that > NumericVersionComparator seems to do a better overall job than > MavenVersionComparator. See hsqldb in the example below for an odd > result using the default comparisonMethod. > > [INFO] The following dependency updates are available: > [INFO] commons-lang:commons-lang .. 2.1 -> 2.4 > [INFO] hsqldb:hsqldb 1.8.0.1 -> 1.7.2-rc1 > > Any chance of using "numeric" as the default method instead? > That would change behaviour from Maven's defaults for version ranges...I'd like maven to make that change not this lone plugin > > I'll add a JIRA project for this plugin and update the POM when I'm done. > > > Stephen Connolly wrote: >> Folks, I've been working on the versions-maven-plugin and I think it's >> ready to cut the first alpha release. >> >> The major changes in this release are >> - Fixed MOJO-1209 (required a rewrite of the display-plugin-updates goal) >> >> Known issues >> >> - MOJO-1210 display-plugin-updates does not include lifecycle plugins >> that are not defined in the pom >> - MOJO-1211 display-plugin-updates does not identify the plugin >> version as not being provided when derived from the super-pom >> >> Both of these issues will require a bit of work and I'd rather get an >> alpha release out before trying to fix them. >> >> The new site has just been deployed here: >> http://mojo.codehaus.org/versions-maven-plugin >> >> Snapshot have been published on >> http://snapshots.repository.codehaus.org/org/codehaus/mojo/versions-maven-plugin >> >> [+1] release it >> [0] don't care >> [-1] don't release ! >> >> Vote will be open for 72 hours and will conclude via lazy consensus. >> >> Please vote :-) >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > -- > Dennis Lundberg > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] release versions-maven-plugin 1.0-alpha-1
On Tue, Sep 2, 2008 at 9:40 PM, Dennis Lundberg <[EMAIL PROTECTED]> wrote: > Hi Stephen > > Great work on this plugin! This is a plugin that I plan to use extensively. > > I've read through the docs, which there are plenty of. Always a good > sign :-) There were however a couple of typos and broken links in there, > which I took the liberty of fixing in SVN. I also updated to mojo-parent 18. > Thanks, I forgot I had to switch back to mojo-parent 18 > After playing around with the plugin a bit I found the results somewhat > confusing, so I started to read the goal parameter docs. There I found > the source of my confusion: the allowSnapshots parameter has true as > default value. In my opinion this should be set to false as default. > Using snapshots is something that should be avoided, if possible. > Showing snapshot versions by default therefor works against best > practices and might lure users to the dark side. > I'm 50:50 on this. I use it to switch all the suit of projects onto SNAPSHOT versions while I'm working on them. When doing a release the release will be the newest version in the repo so puching back to SCM is fine in that case. However I can see the other side. > > I'd like to move the includeProperties, excludeProperties and linkItems > parameters from the Abstract Mojo to UpdatePropertiesMojo, because they > are only used there. Also the parentVersion parameter should be moved to > UpdateParentMojo. Having them in the Abstract Mojo makes them show up as > parameters in the auto generated docs for every Mojo, see [1]. > Fire ahead, when I moved them there I did not have the display goals. > The comparisonMethod parameter is currently only used in > DisplayDependencyUpdatesMojo. Shouldn't it be used in > DisplayPluginUpdatesMojo as well? OK, here is my logic: Maven plugins _should_ be versioned using the Maven version rules, i.e. Major.Minor.Update-Build Dependencies will be versioned using company rules (in our case 5 digits) So you don't need the comparison method for plugins. What do you think? > If not, it can be moved from the Abstract Mojo to > DisplayDependencyUpdatesMojo. Go ahead > > Finally the auto generated docs would benefit from using "default-value" > in the @parameter annotations. This automatically inserts the default > values into the docs. > If you don't mind doing that please > If you want me to, I can have a go at making these changes. > Please do > > [1] > http://mojo.codehaus.org/versions-maven-plugin/display-dependency-updates-mojo.html > > Stephen Connolly wrote: >> Folks, I've been working on the versions-maven-plugin and I think it's >> ready to cut the first alpha release. >> >> The major changes in this release are >> - Fixed MOJO-1209 (required a rewrite of the display-plugin-updates goal) >> >> Known issues >> >> - MOJO-1210 display-plugin-updates does not include lifecycle plugins >> that are not defined in the pom >> - MOJO-1211 display-plugin-updates does not identify the plugin >> version as not being provided when derived from the super-pom >> >> Both of these issues will require a bit of work and I'd rather get an >> alpha release out before trying to fix them. >> >> The new site has just been deployed here: >> http://mojo.codehaus.org/versions-maven-plugin >> >> Snapshot have been published on >> http://snapshots.repository.codehaus.org/org/codehaus/mojo/versions-maven-plugin >> >> [+1] release it >> [0] don't care >> [-1] don't release ! >> >> Vote will be open for 72 hours and will conclude via lazy consensus. >> >> Please vote :-) >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > -- > Dennis Lundberg > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] release versions-maven-plugin 1.0-alpha-1
After trying this plugin on some more projects I have found that NumericVersionComparator seems to do a better overall job than MavenVersionComparator. See hsqldb in the example below for an odd result using the default comparisonMethod. [INFO] The following dependency updates are available: [INFO] commons-lang:commons-lang .. 2.1 -> 2.4 [INFO] hsqldb:hsqldb 1.8.0.1 -> 1.7.2-rc1 Any chance of using "numeric" as the default method instead? I'll add a JIRA project for this plugin and update the POM when I'm done. Stephen Connolly wrote: > Folks, I've been working on the versions-maven-plugin and I think it's > ready to cut the first alpha release. > > The major changes in this release are > - Fixed MOJO-1209 (required a rewrite of the display-plugin-updates goal) > > Known issues > > - MOJO-1210 display-plugin-updates does not include lifecycle plugins > that are not defined in the pom > - MOJO-1211 display-plugin-updates does not identify the plugin > version as not being provided when derived from the super-pom > > Both of these issues will require a bit of work and I'd rather get an > alpha release out before trying to fix them. > > The new site has just been deployed here: > http://mojo.codehaus.org/versions-maven-plugin > > Snapshot have been published on > http://snapshots.repository.codehaus.org/org/codehaus/mojo/versions-maven-plugin > > [+1] release it > [0] don't care > [-1] don't release ! > > Vote will be open for 72 hours and will conclude via lazy consensus. > > Please vote :-) > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] release versions-maven-plugin 1.0-alpha-1
Hi Stephen Great work on this plugin! This is a plugin that I plan to use extensively. I've read through the docs, which there are plenty of. Always a good sign :-) There were however a couple of typos and broken links in there, which I took the liberty of fixing in SVN. I also updated to mojo-parent 18. After playing around with the plugin a bit I found the results somewhat confusing, so I started to read the goal parameter docs. There I found the source of my confusion: the allowSnapshots parameter has true as default value. In my opinion this should be set to false as default. Using snapshots is something that should be avoided, if possible. Showing snapshot versions by default therefor works against best practices and might lure users to the dark side. I'd like to move the includeProperties, excludeProperties and linkItems parameters from the Abstract Mojo to UpdatePropertiesMojo, because they are only used there. Also the parentVersion parameter should be moved to UpdateParentMojo. Having them in the Abstract Mojo makes them show up as parameters in the auto generated docs for every Mojo, see [1]. The comparisonMethod parameter is currently only used in DisplayDependencyUpdatesMojo. Shouldn't it be used in DisplayPluginUpdatesMojo as well? If not, it can be moved from the Abstract Mojo to DisplayDependencyUpdatesMojo. Finally the auto generated docs would benefit from using "default-value" in the @parameter annotations. This automatically inserts the default values into the docs. If you want me to, I can have a go at making these changes. [1] http://mojo.codehaus.org/versions-maven-plugin/display-dependency-updates-mojo.html Stephen Connolly wrote: > Folks, I've been working on the versions-maven-plugin and I think it's > ready to cut the first alpha release. > > The major changes in this release are > - Fixed MOJO-1209 (required a rewrite of the display-plugin-updates goal) > > Known issues > > - MOJO-1210 display-plugin-updates does not include lifecycle plugins > that are not defined in the pom > - MOJO-1211 display-plugin-updates does not identify the plugin > version as not being provided when derived from the super-pom > > Both of these issues will require a bit of work and I'd rather get an > alpha release out before trying to fix them. > > The new site has just been deployed here: > http://mojo.codehaus.org/versions-maven-plugin > > Snapshot have been published on > http://snapshots.repository.codehaus.org/org/codehaus/mojo/versions-maven-plugin > > [+1] release it > [0] don't care > [-1] don't release ! > > Vote will be open for 72 hours and will conclude via lazy consensus. > > Please vote :-) > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] release versions-maven-plugin 1.0-alpha-1
Stephen Connolly schrieb: > Folks, I've been working on the versions-maven-plugin and I think it's > ready to cut the first alpha release. > > The major changes in this release are > - Fixed MOJO-1209 (required a rewrite of the display-plugin-updates goal) > > Known issues > > - MOJO-1210 display-plugin-updates does not include lifecycle plugins > that are not defined in the pom > - MOJO-1211 display-plugin-updates does not identify the plugin > version as not being provided when derived from the super-pom > > Both of these issues will require a bit of work and I'd rather get an > alpha release out before trying to fix them. > > The new site has just been deployed here: > http://mojo.codehaus.org/versions-maven-plugin > > Snapshot have been published on > http://snapshots.repository.codehaus.org/org/codehaus/mojo/versions-maven-plugin > > [+1] release it > [0] don't care > [-1] don't release ! > > Vote will be open for 72 hours and will conclude via lazy consensus. > > Please vote :-) > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > +1 -- Benjamin Voigt Telefon(Buero): (0531) 23 767 36 Mobil: 0174 73 55 242 GOD Gesellsch. fuer Organisation u. Datenverarbeitung mbH Mittelweg 7 38106 Braunschweig Geschaeftsfuehrer: Dietmar Fuehrmann Registergericht: AG Braunschweig Reg.Nr. HRB 2168 http://www.god.de - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] release versions-maven-plugin 1.0-alpha-1
Please don't cross post to the lists. On 1-Sep-08, at 4:07 PM, Stephen Connolly wrote: Folks, I've been working on the versions-maven-plugin and I think it's ready to cut the first alpha release. The major changes in this release are - Fixed MOJO-1209 (required a rewrite of the display-plugin-updates goal) Known issues - MOJO-1210 display-plugin-updates does not include lifecycle plugins that are not defined in the pom - MOJO-1211 display-plugin-updates does not identify the plugin version as not being provided when derived from the super-pom Both of these issues will require a bit of work and I'd rather get an alpha release out before trying to fix them. The new site has just been deployed here: http://mojo.codehaus.org/versions-maven-plugin Snapshot have been published on http://snapshots.repository.codehaus.org/org/codehaus/mojo/versions-maven-plugin [+1] release it [0] don't care [-1] don't release ! Vote will be open for 72 hours and will conclude via lazy consensus. Please vote :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- First, the taking in of scattered particulars under one Idea, so that everyone understands what is being talked about ... Second, the separation of the Idea into parts, by dividing it at the joints, as nature directs, not breaking any limb in half as a bad carver might. -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] release versions-maven-plugin 1.0-alpha-1
i just over looked the the links provided. its seems good. On Mon, Sep 1, 2008 at 7:07 PM, Stephen Connolly < [EMAIL PROTECTED]> wrote: > Folks, I've been working on the versions-maven-plugin and I think it's > ready to cut the first alpha release. > > The major changes in this release are > - Fixed MOJO-1209 (required a rewrite of the display-plugin-updates goal) > > Known issues > > - MOJO-1210 display-plugin-updates does not include lifecycle plugins > that are not defined in the pom > - MOJO-1211 display-plugin-updates does not identify the plugin > version as not being provided when derived from the super-pom > > Both of these issues will require a bit of work and I'd rather get an > alpha release out before trying to fix them. > > The new site has just been deployed here: > http://mojo.codehaus.org/versions-maven-plugin > > Snapshot have been published on > > http://snapshots.repository.codehaus.org/org/codehaus/mojo/versions-maven-plugin > > [+1] release it > [0] don't care > [-1] don't release ! > > Vote will be open for 72 hours and will conclude via lazy consensus. > > Please vote :-) > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
[VOTE] release versions-maven-plugin 1.0-alpha-1
Folks, I've been working on the versions-maven-plugin and I think it's ready to cut the first alpha release. The major changes in this release are - Fixed MOJO-1209 (required a rewrite of the display-plugin-updates goal) Known issues - MOJO-1210 display-plugin-updates does not include lifecycle plugins that are not defined in the pom - MOJO-1211 display-plugin-updates does not identify the plugin version as not being provided when derived from the super-pom Both of these issues will require a bit of work and I'd rather get an alpha release out before trying to fix them. The new site has just been deployed here: http://mojo.codehaus.org/versions-maven-plugin Snapshot have been published on http://snapshots.repository.codehaus.org/org/codehaus/mojo/versions-maven-plugin [+1] release it [0] don't care [-1] don't release ! Vote will be open for 72 hours and will conclude via lazy consensus. Please vote :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
