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] > >>>> > >>>> > >>> > >>> -- > >>> 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] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
