Re: Putting the archetype plugin version in the super POM
Brett Porter wrote: I'm not that tied to the idea, it was just a thought to avoid the potential problem that had been raised by a user. Please consider that such a version lockdown is twofold: It not only saves the user from potential regressions in newer versions but also excludes him from any bugfixes/improvements made in the newer plugin versions, unless you are willing to put the update instructions on each and every doc page out there that mentions the Archetype Plugin. To give an example take the Maven Install Plugin. It's quite irritating to users that they do mvn install:install-file and next they observe Maven trying to download the POM for this artifact. This is due to generatePom defaulting to false in plugin version 2.2 and thanks to the version lock down in the super POM users have no easy way to use the fixed plugin version 2.3 other than giving the fully qualified goal. For reproducible builds, version lockdowns make sense but doing so for CLI plugins IMHO gives evidence of other issues. To me, locking down the Archetype Plugin version translates to that we fear a new version brings more problems than benefits. The proper fix for this would be to increase the test coverage for the plugin. The other related issue is RELEASE vs LATEST. When resolving a plugin version, Maven 2.x prefers LATEST over RELEASE, i.e. Maven 2.x potentially prefers a SNAPSHOT over a proper release. IIRC, it was an IRC discussion with Arnaud where we seemed to agree that this behavior is not really helpful to the majority of ordinary users. So this might be something to review for Maven 2.x as well. Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Putting the archetype plugin version in the super POM
We should endeavour to leave only the build time related plugins being locked down. Things like the IDE generating plugins, the site stuff, and archetype stuff should all be removed eventually and decoupled from the core entirely. We're just making a bigger mess tying all this stuff together and trying to maintain it as a functioning unit in lock step. If you read the original discussions about this feature it was done for one reason only: To try and prevent people's builds from breaking just because we release a new core plugin. It was intentional that we only included plugins that are typically bound to lifecycles in addition to core ones (this includes enforcer, dependency, assembly etc). Help, eclipse, idea, archetype are in the same group to me and that is cli use only. Putting these things in the super pom was a crutch but the benefit of stable builds outweighted the downsides, for cli use plugins I don't see this benefit. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Putting the archetype plugin version in the super POM
On 01/02/2010, at 10:57 PM, Benjamin Bentmann wrote: Brett Porter wrote: I'm not that tied to the idea, it was just a thought to avoid the potential problem that had been raised by a user. Please consider that such a version lockdown is twofold: It not only saves the user from potential regressions in newer versions but also excludes him from any bugfixes/improvements made in the newer plugin versions, unless you are willing to put the update instructions on each and every doc page out there that mentions the Archetype Plugin. Yup, I understand it's a tradeoff, and that's why I wanted to be clear it was an exception for Archetype, not other CLI plugins - but I do see your point. The proper fix for this would be to increase the test coverage for the plugin. Couldn't agree more :) The other related issue is RELEASE vs LATEST. When resolving a plugin version, Maven 2.x prefers LATEST over RELEASE, i.e. Maven 2.x potentially prefers a SNAPSHOT over a proper release. Yep, when I was proposing this I was under the impression that both snapshots and releases would be regularly obtained. With Maven 3 preferring RELEASE, and with MNG-4554 fixed (thanks!), I see very little need for the exception, so I'll close the issue out. IIRC, it was an IRC discussion with Arnaud where we seemed to agree that this behavior is not really helpful to the majority of ordinary users. So this might be something to review for Maven 2.x as well. I'm not sure what you talked about, but if Arnaud wants to implement it for 2.x that's fine by me. I just don't think it's a 2.2.2 thing, and at this stage we haven't made any plans for a 2.3. I'm still in favour of a 2.3 that provides a stepping stone to 3.0 with changes like this, but I'd personally rather focus on 3.0 once we get past the planned releases. - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Putting the archetype plugin version in the super POM
On 29/01/2010, at 5:37 PM, Jason van Zyl wrote: On 2010-01-29, at 6:29 AM, Brett Porter wrote: On 29/01/2010, at 4:26 PM, Jason van Zyl wrote: -1 got a reason? :) We should endeavour to leave only the build time related plugins being locked down. Things like the IDE generating plugins, the site stuff, and archetype stuff should all be removed eventually and decoupled from the core entirely. We're just making a bigger mess tying all this stuff together and trying to maintain it as a functioning unit in lock step. I'm not sure that's addressing the same concern - I know there are problems with, say, the site plugin, being too coupled into the core, but locking down versions is a bit of a different matter. Even then, I agree with what you've said, but it seems like archetype might be a worthy exception since it's the first thing many users hit and used regularly by established users, and it has bitten us before. Even today, Maven 3 regularly updates release versions of the plugin so as soon as something is in the wild it'll get picked up (this may be a bug though - I'll add that to JIRA). I'm not that tied to the idea, it was just a thought to avoid the potential problem that had been raised by a user. I'd hoped to hear a few other opinions either way... if no one else speaks up in favour I'll just close the issue as 'won't fix'. - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Putting the archetype plugin version in the super POM
On Thu, Jan 14, 2010 at 6:33 PM, Brett Porter br...@apache.org wrote: I think this has come up before and we wanted to avoid doing it for things on the command line, where it is hard to override. In general that would be true, but for the archetype plugin being the first experience people have with Maven, a bit more reliability would probably be useful. I thought we could apply the patch below in 2.2.2. This would by default lock it down, but allow the comparatively simple cmd line to get a different version: $ mvn archetype:generate -Dmaven.archetype.version=2.0-alpha-6-SNAPSHOT Can't you already specify the version with the long form mvn org.apache.maven.plugins:maven-archetype-plugin:VERSION:generate (which doesn't look like that much more typing, and sticks to an established convention) ? -- Wendy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Putting the archetype plugin version in the super POM
On 01/02/2010, at 2:01 PM, Wendy Smoak wrote: On Thu, Jan 14, 2010 at 6:33 PM, Brett Porter br...@apache.org wrote: I think this has come up before and we wanted to avoid doing it for things on the command line, where it is hard to override. In general that would be true, but for the archetype plugin being the first experience people have with Maven, a bit more reliability would probably be useful. I thought we could apply the patch below in 2.2.2. This would by default lock it down, but allow the comparatively simple cmd line to get a different version: $ mvn archetype:generate -Dmaven.archetype.version=2.0-alpha-6-SNAPSHOT Can't you already specify the version with the long form mvn org.apache.maven.plugins:maven-archetype-plugin:VERSION:generate (which doesn't look like that much more typing, and sticks to an established convention) ? That wouldn't allow setting it in settings.xml, so you'd have to type the longer version every time. - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Putting the archetype plugin version in the super POM
On 15/01/2010, at 1:45 PM, Brett Porter wrote: On 15/01/2010, at 12:42 PM, Benjamin Bentmann wrote: Brett Porter wrote: Perhaps we might only do it for 3.0 if that's the case (esp. since this has a very minor chance of incompatibility if the property is in use). Why has the version to be locked down in the first place? Is it to prevent usage of a snapshot version? If so, I don't think this applies to 3.0 as it prefers RELEASE over LATEST. Ah, I had forgotten about that. That was probably the main reason, but it is also valuable to protect the releases. I think these were ones we got bitten by before: http://markmail.org/message/if6sbrsvr2zrvkta http://markmail.org/message/fgopqlnnhuecfmnq We are likely more careful with the releases, but as it's something that immediately affects all users on a new release, it's probably a little disconcerting. Benjamin, others - any further thoughts on this? I'm still inclined towards adding it. - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Putting the archetype plugin version in the super POM
-1 On 2010-01-29, at 6:15 AM, Brett Porter wrote: On 15/01/2010, at 1:45 PM, Brett Porter wrote: On 15/01/2010, at 12:42 PM, Benjamin Bentmann wrote: Brett Porter wrote: Perhaps we might only do it for 3.0 if that's the case (esp. since this has a very minor chance of incompatibility if the property is in use). Why has the version to be locked down in the first place? Is it to prevent usage of a snapshot version? If so, I don't think this applies to 3.0 as it prefers RELEASE over LATEST. Ah, I had forgotten about that. That was probably the main reason, but it is also valuable to protect the releases. I think these were ones we got bitten by before: http://markmail.org/message/if6sbrsvr2zrvkta http://markmail.org/message/fgopqlnnhuecfmnq We are likely more careful with the releases, but as it's something that immediately affects all users on a new release, it's probably a little disconcerting. Benjamin, others - any further thoughts on this? I'm still inclined towards adding it. - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ - 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 -- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Putting the archetype plugin version in the super POM
On 29/01/2010, at 4:26 PM, Jason van Zyl wrote: -1 got a reason? :) On 2010-01-29, at 6:15 AM, Brett Porter wrote: On 15/01/2010, at 1:45 PM, Brett Porter wrote: On 15/01/2010, at 12:42 PM, Benjamin Bentmann wrote: Brett Porter wrote: Perhaps we might only do it for 3.0 if that's the case (esp. since this has a very minor chance of incompatibility if the property is in use). Why has the version to be locked down in the first place? Is it to prevent usage of a snapshot version? If so, I don't think this applies to 3.0 as it prefers RELEASE over LATEST. Ah, I had forgotten about that. That was probably the main reason, but it is also valuable to protect the releases. I think these were ones we got bitten by before: http://markmail.org/message/if6sbrsvr2zrvkta http://markmail.org/message/fgopqlnnhuecfmnq We are likely more careful with the releases, but as it's something that immediately affects all users on a new release, it's probably a little disconcerting. Benjamin, others - any further thoughts on this? I'm still inclined towards adding it. - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ - 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 -- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Putting the archetype plugin version in the super POM
On 2010-01-29, at 6:29 AM, Brett Porter wrote: On 29/01/2010, at 4:26 PM, Jason van Zyl wrote: -1 got a reason? :) We should endeavour to leave only the build time related plugins being locked down. Things like the IDE generating plugins, the site stuff, and archetype stuff should all be removed eventually and decoupled from the core entirely. We're just making a bigger mess tying all this stuff together and trying to maintain it as a functioning unit in lock step. On 2010-01-29, at 6:15 AM, Brett Porter wrote: On 15/01/2010, at 1:45 PM, Brett Porter wrote: On 15/01/2010, at 12:42 PM, Benjamin Bentmann wrote: Brett Porter wrote: Perhaps we might only do it for 3.0 if that's the case (esp. since this has a very minor chance of incompatibility if the property is in use). Why has the version to be locked down in the first place? Is it to prevent usage of a snapshot version? If so, I don't think this applies to 3.0 as it prefers RELEASE over LATEST. Ah, I had forgotten about that. That was probably the main reason, but it is also valuable to protect the releases. I think these were ones we got bitten by before: http://markmail.org/message/if6sbrsvr2zrvkta http://markmail.org/message/fgopqlnnhuecfmnq We are likely more careful with the releases, but as it's something that immediately affects all users on a new release, it's probably a little disconcerting. Benjamin, others - any further thoughts on this? I'm still inclined towards adding it. - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ - 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 -- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ - 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 -- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Putting the archetype plugin version in the super POM
I think this has come up before and we wanted to avoid doing it for things on
the command line, where it is hard to override. In general that would be true,
but for the archetype plugin being the first experience people have with Maven,
a bit more reliability would probably be useful.
I thought we could apply the patch below in 2.2.2. This would by default lock
it down, but allow the comparatively simple cmd line to get a different version:
$ mvn archetype:generate -Dmaven.archetype.version=2.0-alpha-6-SNAPSHOT
Or the corresponding change permanently in settings.xml:
profile
idproperties/id
properties
maven.archetype.version2.0-alpha-6-SNAPSHOT/maven.archetype.version
/properties
/profile
...
activeProfiles
activeProfileproperties/activeProfile
/activeProfiles
The downside is that at the moment this works for settings the version
correctly when a pom.xml exists, but not when one doesn't (which I think might
be a bug in 2.2.2 that would also need fixing). I haven't checked trunk but it
might work there already. Perhaps we might only do it for 3.0 if that's the
case (esp. since this has a very minor chance of incompatibility if the
property is in use).
I wouldn't want to do this for every plugin - having magic properties is
something to be wary of - but this one might be worthwhile as a special case?
Thoughts?
- Brett
Index: maven-project/src/main/resources/org/apache/maven/project/pom-4.0.0.xml
===
--- maven-project/src/main/resources/org/apache/maven/project/pom-4.0.0.xml
(revision 899508)
+++ maven-project/src/main/resources/org/apache/maven/project/pom-4.0.0.xml
(working copy)
@@ -68,9 +68,13 @@
directory${project.basedir}/src/test/resources/directory
/testResource
/testResources
- pluginManagement
- plugins
+pluginManagement
+ plugins
plugin
+ artifactIdmaven-archetype-plugin/artifactId
+ version${maven.archetype.version}/version
+ /plugin
+ plugin
artifactIdmaven-antrun-plugin/artifactId
version1.3/version
/plugin
@@ -204,6 +208,8 @@
/build
/profile
/profiles
-
+ properties
+maven.archetype.version2.0-alpha-4/maven.archetype.version
+ /properties
/project
--
Brett Porter
br...@apache.org
http://brettporter.wordpress.com/
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Putting the archetype plugin version in the super POM
Brett Porter wrote: Perhaps we might only do it for 3.0 if that's the case (esp. since this has a very minor chance of incompatibility if the property is in use). Why has the version to be locked down in the first place? Is it to prevent usage of a snapshot version? If so, I don't think this applies to 3.0 as it prefers RELEASE over LATEST. Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Putting the archetype plugin version in the super POM
On 15/01/2010, at 12:42 PM, Benjamin Bentmann wrote: Brett Porter wrote: Perhaps we might only do it for 3.0 if that's the case (esp. since this has a very minor chance of incompatibility if the property is in use). Why has the version to be locked down in the first place? Is it to prevent usage of a snapshot version? If so, I don't think this applies to 3.0 as it prefers RELEASE over LATEST. Ah, I had forgotten about that. That was probably the main reason, but it is also valuable to protect the releases. I think these were ones we got bitten by before: http://markmail.org/message/if6sbrsvr2zrvkta http://markmail.org/message/fgopqlnnhuecfmnq We are likely more careful with the releases, but as it's something that immediately affects all users on a new release, it's probably a little disconcerting. - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
