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]
