Re: Plugin Versions in the Super pom
That's nice, so I reconsider my vote as -0 : only a fix until plugin version are required by maven 2.1, but I had prefered the equivalent enforcer code to be integrated to core and WARN (optionally FAIL) when no plugin version is specified. This would be - more educational - a good preparation for new 2.1 requirements Proposal to set plugins version fix unstable behavior but does not educate users. About I don't want a huge XML, maybe we should consider updating Modello to use attributes as an alternative to verbose XML elements. We could use namespaces to avoid conflict with 2.0 schema ... but that should be dicussed in another thread ! Nico. 2008/2/10, Brian E. Fox [EMAIL PROTECTED]: Yes, I had to walk the poms in the rule to see if the version was specified anywhere. (the model in project always has versions filled in, even if they aren't actually specified in the poms.) The code stops walking up the pom tree when there is no parent specified and it doesn't look in the super pom. The net result is that if you haven't locked down your versions and you use the requirePluginVersions rule, then it will fail just like it does today. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of nicolas de loof Sent: Saturday, February 09, 2008 11:05 PM To: Maven Developers List; [EMAIL PROTECTED] Subject: Re: Plugin Versions in the Super pom Could the enforcer plugin still warn about missing plugins version if they are set in the super POM ? Nico 2008/2/10, Ralph Goers [EMAIL PROTECTED]: In my world I require a reproduceable build. Typically, that means a specific release would have to be built using a specific version of Maven. Any attempt to build it at a later time would need to still use that release. This isn't just because of default versions of plugins but because the behavior of Maven itself might have changed. Now, while I think it is great to have default versions of plugins, when push comes to shove I won't really care. Just like I will use my own managed dependency specifications to control dependency versions I would also recommend explicitly controlling the plugin versions used. I'm not a big fan of letting Maven dynamically pick versions of anything as it leads to a build which can't be reliably recreated. So if this proposal means that each version of Maven hard-wires default versions of plugins - but that those plugin versions can be overridden then I definitely agree that that is the correct way to go. Ralph nicolas de loof wrote: I have to change my vote to -1 : Current maven behavior introduces some issues when plugin version is not set. Many users got errors with this and learned to use version. Having maven super-POM set plugin version will make the build depend on maven version used. Simple scenario : I create a project with maven 2.0.9, wich introduces superPOM with versionned plugins. My build is reproductible even when new plugins are released. This DOESN't learn me best-practices about plugins versionning. Latter I come back to this project for maintenance with maven 2.0.11, that I expect to be backward compatible. As not beeing a hacker I don't even know what version of maven I'm using, simply run some eclipse integration (maybe we will have some one day or the other) ... and the project gets broken as 2.0.11 superPOM doesn't set the same plugins ! I got such scenario in REAL-WORLD projects using maven1 : maintenance developers (maven newbees) had errors when building the project ... because maven 1.1 was installed as default on the developer environment, and the project used maven 1.0.2 with some uncompatible plugins. - 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: Plugin Versions in the Super pom
2. Those who have not locked their versions down By the way, this includes Maven itself. For instance, I see plugin builds that fetch other plugin SNAPSHOTs from my local repo that I have built for testing patches. As a matter of advertising, it might be helpful if the Maven sources would give a good example ;-) Regards, Benjamin Bentmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Plugin Versions in the Super pom
Of course they should :-) If you have anything specific, please file it in JIRA or send a mail here and I'll take care of it. Don't worry, once enforcer goes out, I'll be setting up our poms to get it all locked down. As I mentioned in my previous email, I've been manually doing it in the meantime. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Plugin Versions in the Super pom
As a matter of advertising, it might be helpful if the Maven sources would give a good example ;-) Absolutely. I have started doing this with all my releases (I use the enforcer snapshot to find them, then take it out for now). 2.0.8, dependency and archetype all have things locked down. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plugin Versions in the Super pom
Benjamin Bentmann wrote: 2. Those who have not locked their versions down By the way, this includes Maven itself. For instance, I see plugin builds that fetch other plugin SNAPSHOTs from my local repo that I have built for testing patches. As a matter of advertising, it might be helpful if the Maven sources would give a good example ;-) Of course they should :-) If you have anything specific, please file it in JIRA or send a mail here and I'll take care of it. Regards, Benjamin Bentmann -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plugin Versions in the Super pom
If you have anything specific Some Maven or Mojo plugins... please file it in JIRA Sorry, but I won't due to my laziness ;-). In lack of a reportingManagement in Maven 2.0, one cannot do this simply by means of a single updated parent POM but would really need to update each sub module POM. I think that's something plugin authors can do on their own. Regards, Benjamin Bentmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plugin Versions in the Super pom
On 10-Feb-08, at 1:59 PM, Benjamin Bentmann wrote: 2.0.8, dependency and archetype all have things locked down. In case you meant the maven-dependency-plugin: [INFO] Scanning for projects... [INFO] [INFO] Building Maven Dependency Plugin [INFO]task-segment: [site] [INFO] [INFO] snip:maven-plugin-plugin: checking for updates from central [INFO] snip:maven-project-info-reports-plugin: checking for updates from central ... [INFO] snip:maven-stylus-skin: checking for updates from central That's not what I understand as a version lock down. Sure, the site might not be that important but I still would like it to be as reproducible as anything else I can generate out of a given POM. I use the enforcer snapshot to find them Then I would like to ask to extend the RequirePluginVersions rule to check reporting plugins as well. I think another rule would be more appropriate. We already have a lot of confusion in the core because plugins and reports are treated the same some places, and different in other places. It's easy enough to have a another rule and then prevent questions like why does the plugin rule apply to my reports?, or why doesn't the plugin rule apply to my reports?. We'll have one for each. Otherwise, chances are that people lock maven-surefire-plugin down to 2.4.1 but forget the version for maven-surefire-report-plugin and end up with version 3.x some day that fails to properly handle some older report formats. Just one example. Regards, Benjamin Bentmann - 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 -- Simplex sigillum veri. (Simplicity is the seal of truth.) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plugin Versions in the Super pom
2.0.8, dependency and archetype all have things locked down. In case you meant the maven-dependency-plugin: [INFO] Scanning for projects... [INFO] [INFO] Building Maven Dependency Plugin [INFO]task-segment: [site] [INFO] [INFO] snip:maven-plugin-plugin: checking for updates from central [INFO] snip:maven-project-info-reports-plugin: checking for updates from central ... [INFO] snip:maven-stylus-skin: checking for updates from central That's not what I understand as a version lock down. Sure, the site might not be that important but I still would like it to be as reproducible as anything else I can generate out of a given POM. I use the enforcer snapshot to find them Then I would like to ask to extend the RequirePluginVersions rule to check reporting plugins as well. Otherwise, chances are that people lock maven-surefire-plugin down to 2.4.1 but forget the version for maven-surefire-report-plugin and end up with version 3.x some day that fails to properly handle some older report formats. Just one example. Regards, Benjamin Bentmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Plugin Versions in the Super pom
That's not what I understand as a version lock down. Sure, the site might not be that important but I still would like it to be as reproducible as anything else I can generate out of a given POM. The reporting is the last piece and is the reason I haven't released the enforcer yet. The report plugin handling in Maven is well, retarded imnsho. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plugin Versions in the Super pom
Just please somebody implement either enforcer:display-plugin-versions or help:display-plugin-versions On Feb 10, 2008 10:37 PM, Jason van Zyl [EMAIL PROTECTED] wrote: The enforcer is entirely pluggable so that wouldn't be a problem if someone wanted to implement that. On 10-Feb-08, at 2:29 PM, Benjamin Bentmann wrote: I think another rule would be more appropriate. Sounds reasonable, two different POM elements, two different rules. To make things complete a third rule would be RequireSkinVersion. Benjamin - 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 -- In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plugin Versions in the Super pom
The enforcer is entirely pluggable so that wouldn't be a problem if someone wanted to implement that. On 10-Feb-08, at 2:29 PM, Benjamin Bentmann wrote: I think another rule would be more appropriate. Sounds reasonable, two different POM elements, two different rules. To make things complete a third rule would be RequireSkinVersion. Benjamin - 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 -- In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plugin Versions in the Super pom
I think another rule would be more appropriate. Sounds reasonable, two different POM elements, two different rules. To make things complete a third rule would be RequireSkinVersion. Benjamin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plugin Versions in the Super pom
If the whole plugin versions in the super pom goes ahead, which I think is a good idea by the way. It may be useful to release Maven more often, so that the super pom gets updates on a more regular basis, i.e. at least once a month. I know releases are getting more regular, but from my experience on the Hudson project, release early, release often is far better than the long release cycles, e.g. 2.0.4 to 2.0.5. Of course Hudson is release early - release often on steriods! ;-) - Stephen
Re: Plugin Versions in the Super pom
Um - any reason that 2.0.8.1 can't be released that only contains an update to the superpom's plugin-set? (again, assuming this line of action is pursued) Christian. On 10-Feb-08, at 18:18 , Stephen Connolly wrote: If the whole plugin versions in the super pom goes ahead, which I think is a good idea by the way. It may be useful to release Maven more often, so that the super pom gets updates on a more regular basis, i.e. at least once a month. I know releases are getting more regular, but from my experience on the Hudson project, release early, release often is far better than the long release cycles, e.g. 2.0.4 to 2.0.5. Of course Hudson is release early - release often on steriods! ;-) - Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Plugin Versions in the Super pom
Just please somebody implement either enforcer:display-plugin-versions or help:display-plugin-versions The code to do this is in the enforcer rule now, once I get the rule solidified and released, I'll move it to a common piece and add it to help. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Plugin Versions in the Super pom
Um - any reason that 2.0.8.1 can't be released that only contains an update to the superpom's plugin-set? (again, assuming this line of action is pursued) It seems pretty certain to me that this is going to happen. I'd rather see 2.0.9 come out, but naturally sooner rather than later and I know there are some issues people have been waiting a long time on. Unfortunately they still don't have patches and aren't fixed so they may have to get bumped unless we can find someone/time to fix them. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Plugin Versions in the Super pom
It may be useful to release Maven more often, so that the super pom gets updates on a more regular basis, i.e. at least once a month. In general I agree we need to release more often and intend to make sure it starts happening. I will not however consider a release simply to update the super pom. One of the benefits to having the plugins in the super pom is that people will be motivated to update their plugin rather than waiting for a maven release. This will teach and encourage the real best practice, which is to lock down your revs. Ideally no one should care about the plugin versions in the super poms and this is just the first step to help us get there. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plugin Versions in the Super pom
+1 I've allready done similar fix common plugins version work in my corporate POM, with version set for all org.apache.maven.plugins and many org.codehaus.mojo. Recent release of surefire plugin demonstrates many users suffering from the get latest plugin policy, and some builds not beeing reproductible anymore. Nico. 2008/2/9, Brian E. Fox [EMAIL PROTECTED]: I know it's been discussed before in the context of various other issues and solutions, but I want to discuss locking down core plugins in the super pom _for_ 2.0 _only_. Normally we get into some large protracted discussions about better solutions and drawbacks/benefits of them, meanwhile the users suffer the wrath of auto plugin updates. Considering the amount of time I spent writing the enforcer requirePluginVersions rule, you can safely assume you don't need to convince me that the _right_ way is to lock them down in your poms. I already believe that. I also think that there is probably a better solution, whether it's plugin packs (which I don't agree with at this point) or something else. We can agree that whatever else it is that may be done will come in 2.1 and for a large portion of users 2.1 in production is a long way off and we continue to suffer bad press about the instability of Maven in the mean time. So I'd like to put those discussions aside for now and simply discuss the ramifications of defaulting the core plugin versions in the super pom in 2.0 only. I see two main benefits: 1. Those who have followed best practice and locked their versions down will not be affected by this at all. The normal inheritance rules will apply, and we'll put these versions into the pluginManagement section of the super pom. 2. Those who have not locked their versions down will only be affected by gaining stability in between maven releases. If they want a new plugin before the next Maven release, they will have to follow the best practices and lock their version down to the new version. (this actually informs people and encourages them to learn how to do that...but when _they_ are ready to do it because they are motivated to grab a new release, not when they least expect it because we pushed out a plugin that broke their build) 3. The change is very simple, can be done quickly and has little harm of creating more problems. The only drawback I can see is that it lulls people into a false sense of security because _less_ plugins auto update Not all of them. Certainly we won't lock down every plugin in existence and those plugins will still be subjected to the auto update. Again, I'm not suggesting we solve the world here, but this is a simple step forward to reduce the impact of one of the most frequent complaints of the users. If you can think of some serious drawbacks to this approach, speak now for forever hold your peace ;-) --Brian
Re: Plugin Versions in the Super pom
I have to change my vote to -1 : Current maven behavior introduces some issues when plugin version is not set. Many users got errors with this and learned to use version. Having maven super-POM set plugin version will make the build depend on maven version used. Simple scenario : I create a project with maven 2.0.9, wich introduces superPOM with versionned plugins. My build is reproductible even when new plugins are released. This DOESN't learn me best-practices about plugins versionning. Latter I come back to this project for maintenance with maven 2.0.11, that I expect to be backward compatible. As not beeing a hacker I don't even know what version of maven I'm using, simply run some eclipse integration (maybe we will have some one day or the other) ... and the project gets broken as 2.0.11 superPOM doesn't set the same plugins ! I got such scenario in REAL-WORLD projects using maven1 : maintenance developers (maven newbees) had errors when building the project ... because maven 1.1 was installed as default on the developer environment, and the project used maven 1.0.2 with some uncompatible plugins. I'd suggest another way to go : Change maven to read the POM prerequisites and warn when installed maven ISN't the one expected (could it accept version ranges ?). Or better : make maven core automatically downgrade to expected runtime jars ? Change the release plugin to require plugin version for all plugins (the one configured + the one used by the packaging lifecycle). Change maven to INFO when an unversionned plugin is used during build. Some best practice is to set plugin version ... message would educate users. As an alternative, the super POM could be published on central and not be part of maven classpath, so that a project could set the version of this superPOM to be used. Maven could BY DEFAULT use the one that matches running maven version, and maybe log some best-practice info. Nico. 2008/2/9, nicolas de loof [EMAIL PROTECTED]: +1 I've allready done similar fix common plugins version work in my corporate POM, with version set for all org.apache.maven.plugins and many org.codehaus.mojo. Recent release of surefire plugin demonstrates many users suffering from the get latest plugin policy, and some builds not beeing reproductible anymore. Nico. 2008/2/9, Brian E. Fox [EMAIL PROTECTED]: I know it's been discussed before in the context of various other issues and solutions, but I want to discuss locking down core plugins in the super pom _for_ 2.0 _only_. Normally we get into some large protracted discussions about better solutions and drawbacks/benefits of them, meanwhile the users suffer the wrath of auto plugin updates. Considering the amount of time I spent writing the enforcer requirePluginVersions rule, you can safely assume you don't need to convince me that the _right_ way is to lock them down in your poms. I already believe that. I also think that there is probably a better solution, whether it's plugin packs (which I don't agree with at this point) or something else. We can agree that whatever else it is that may be done will come in 2.1 and for a large portion of users 2.1 in production is a long way off and we continue to suffer bad press about the instability of Maven in the mean time. So I'd like to put those discussions aside for now and simply discuss the ramifications of defaulting the core plugin versions in the super pom in 2.0 only. I see two main benefits: 1. Those who have followed best practice and locked their versions down will not be affected by this at all. The normal inheritance rules will apply, and we'll put these versions into the pluginManagement section of the super pom. 2. Those who have not locked their versions down will only be affected by gaining stability in between maven releases. If they want a new plugin before the next Maven release, they will have to follow the best practices and lock their version down to the new version. (this actually informs people and encourages them to learn how to do that...but when _they_ are ready to do it because they are motivated to grab a new release, not when they least expect it because we pushed out a plugin that broke their build) 3. The change is very simple, can be done quickly and has little harm of creating more problems. The only drawback I can see is that it lulls people into a false sense of security because _less_ plugins auto update Not all of them. Certainly we won't lock down every plugin in existence and those plugins will still be subjected to the auto update. Again, I'm not suggesting we solve the world here, but this is a simple step forward to reduce the impact of one of the most frequent complaints of the users. If you can think of some serious drawbacks to this approach, speak now for forever hold your peace ;-) --Brian
Re: Plugin Versions in the Super pom
simply discuss the ramifications of defaulting the core plugin versions in the super pom in 2.0 only. +1, might also spare users from learning yet another concept like plugin-packs. If the super POM locks down all plugins that would be injected by one of the various lifecycle mappings and the user himself locks down any additional plugins he explicitly configured in the POM, why bother with something like plugin-packs. Besides, I do not see much value in an attempt to pack/group plugins given the fact that each plugin has its own release cycle, i.e. there are more version combinations of plugins from which I want to choose than you want to provide plugin packs for. Last but least and please don't take this as an offense but if you are honest you have to confess that implementation of inheritance is buggy/complex enough. As a user interested in a stable build tool, I really dislike the idea of another concept that interferes with plugin resolution. Those who have followed best practice and locked their versions down will not be affected by this at all. The reality looks different: http://jira.codehaus.org/browse/MNG-3394 As a prerequisite for the proposed additions to the super POM, this issue should be fixed. Regards, Benjamin Bentmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plugin Versions in the Super pom
+1 in principle. One thought thoughwhat if we were to add the activeProfile element as it exists in the settings.xml into the pom.xml and advertise that users can set something like this in their top level pom.xml: profiles activeProfiles activeProfiledefault-maven-plugin-versioning/activeProfile /activeProfiles /profiles This lets the behavior be optional, to be enabled as desired, is additive to the pom.xml and accomplishes all of the same goals. We advertise the hell out of it and people will discover it as they have a problem that they resolve, can migrate to it as an upgrade process in their company environments and we don't screw someone over with our benevolent power. thoughts? jesse On Feb 9, 2008 7:59 AM, Benjamin Bentmann [EMAIL PROTECTED] wrote: simply discuss the ramifications of defaulting the core plugin versions in the super pom in 2.0 only. +1, might also spare users from learning yet another concept like plugin-packs. If the super POM locks down all plugins that would be injected by one of the various lifecycle mappings and the user himself locks down any additional plugins he explicitly configured in the POM, why bother with something like plugin-packs. Besides, I do not see much value in an attempt to pack/group plugins given the fact that each plugin has its own release cycle, i.e. there are more version combinations of plugins from which I want to choose than you want to provide plugin packs for. Last but least and please don't take this as an offense but if you are honest you have to confess that implementation of inheritance is buggy/complex enough. As a user interested in a stable build tool, I really dislike the idea of another concept that interferes with plugin resolution. Those who have followed best practice and locked their versions down will not be affected by this at all. The reality looks different: http://jira.codehaus.org/browse/MNG-3394 As a prerequisite for the proposed additions to the super POM, this issue should be fixed. Regards, Benjamin Bentmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED]
RE: Plugin Versions in the Super pom
We advertise the hell out of it and people will discover it as they have a problem that they resolve, can migrate to it as an upgrade process in their company environments and we don't screw someone over with our benevolent power. I think the biggest beef people have is that we are unstable by default. I don't think that requiring some action to get the versions locked is really going to help much. Otherwise we just continue to advertise the hell out of locking down your versions in the pom (which hasn't been working). --Brian
RE: Plugin Versions in the Super pom
snip comments about plugin packs that I happen to agree with The reality looks different: http://jira.codehaus.org/browse/MNG-3394 As a prerequisite for the proposed additions to the super POM, this issue should be fixed. Yes. I moved it to 2.0.9 as this definitely is related. --Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plugin Versions in the Super pom
Brian E. Fox wrote: We advertise the hell out of it and people will discover it as they have a problem that they resolve, can migrate to it as an upgrade process in their company environments and we don't screw someone over with our benevolent power. I think the biggest beef people have is that we are unstable by default. I don't think that requiring some action to get the versions locked is really going to help much. Otherwise we just continue to advertise the hell out of locking down your versions in the pom (which hasn't been working). --Brian A tiny inexperienced voice from the user side of things chiming in here... For me, I am completely aware that I want to lock *everything* down (including plugins) to have reproducible builds. So marketing, advertising, pleading with us, educating us is not the issue. The problem is not knowing or being able to keep up with the list of what combination of plugins and maven versions work well together. Whether or not the list of plugin versions is in the super POM is not the isue for me. It is the wisdom and experience of the person who would make the choices of which versions of the plugins to put in that default list that is the real value. In general I don't want to have to make those choices for every plugin -- just the occasional exception for when I really need some new feature or old compatibility. Either of two approaches would satisfy me: 1) Benevolent dictators strongly suggest the list of plugin versions which are thought to be stable together and that is in the super POM or I just cut-n-paste the suggested list in there myself from the web site. 2) I just go ahead and try my build process using all the latest plugin versions (current default behavior) and then when I see that they all work together have some mechanism to freeze the list and have the current versions (whatever they are) automatically written into my POM without me having to sort through and figure out what the versions are and manually insert them into the POM. I would want to be able to freeze the list not just at release time but at any arbitrary time to stabilize the development environment for my team. Thanks. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Plugin Versions in the Super pom
I have to change my vote to -1 : Current maven behavior introduces some issues when plugin version is not set. Many users got errors with this and learned to use version. Having maven super-POM set plugin version will make the build depend on maven version used. Compare this change to the current behavior. People simply are not locking them down either because they don't know or they don't want to make huge xmls. (remember I still think locking them down is the right way to do it, but apparently the majority of the users don't/won't). So if we do nothing, they are just as likely to have un-reproducible builds with a later version of maven. And worse, they potentially break across developers because their machines have different versions and it changes suddenly without them having any interaction. What you point out is definitely a risk, but I see it as less harmful than the current method. --Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plugin Versions in the Super pom
On 9-Feb-08, at 5:53 AM, nicolas de loof wrote: I have to change my vote to -1 : Current maven behavior introduces some issues when plugin version is not set. Many users got errors with this and learned to use version. Having maven super-POM set plugin version will make the build depend on maven version used. Simple scenario : I create a project with maven 2.0.9, wich introduces superPOM with versionned plugins. My build is reproductible even when new plugins are released. This DOESN't learn me best-practices about plugins versionning. We all fully realize that. The change is to help the unsuspecting, and the general user who is not going to read anything and just expects not to be surprised. This helps the general situation irrespective of people learning best practices. It provides a higher degree of stability people should be setting versions. It's the nature of users. Latter I come back to this project for maintenance with maven 2.0.11, that I expect to be backward compatible. As not beeing a hacker I don't even know what version of maven I'm using, simply run some eclipse integration (maybe we will have some one day or the other) Yes, but in the meantime they have had stability. If they had plugins that weren't versioned they could have been broken any number of places from the switch to different versions of Maven. ... and the project gets broken as 2.0.11 superPOM doesn't set the same plugins ! Overall the stability is still increased. I got such scenario in REAL-WORLD projects using maven1 : maintenance developers (maven newbees) had errors when building the project ... because maven 1.1 was installed as default on the developer environment, and the project used maven 1.0.2 with some uncompatible plugins. I'd suggest another way to go : Change maven to read the POM prerequisites and warn when installed maven ISN't the one expected (could it accept version ranges ?). Or better : make maven core automatically downgrade to expected runtime jars ? Too complicated. Using the enforcer plugin setting the Maven version would prevent a problem from happening. Prerequisites are not for setting the user's version of Maven, it's for setting the requirement of the plugin. Change the release plugin to require plugin version for all plugins (the one configured + the one used by the packaging lifecycle). Too complicated, and people might not use the release plugin. Change maven to INFO when an unversionned plugin is used during build. Some best practice is to set plugin version ... message would educate users. The enforcer plugin with the right rules can already do this (when it's released, ahem, Brian :-)) As an alternative, the super POM could be published on central and not be part of maven classpath, so that a project could set the version of this superPOM to be used. Maven could BY DEFAULT use the one that matches running maven version, and maybe log some best-practice info. Too complicated. You're asking for a far more complicated solutions to be implemented which generally aren't much more helpful. You're also conflating the solution with what people should do and what they should actually be doing. Yes, people should use versions for their plugins, but in the absence of that putting the versions in the POM is the easiest solution to provide the most stability, in most cases. Nico. 2008/2/9, nicolas de loof [EMAIL PROTECTED]: +1 I've allready done similar fix common plugins version work in my corporate POM, with version set for all org.apache.maven.plugins and many org.codehaus.mojo. Recent release of surefire plugin demonstrates many users suffering from the get latest plugin policy, and some builds not beeing reproductible anymore. Nico. 2008/2/9, Brian E. Fox [EMAIL PROTECTED]: I know it's been discussed before in the context of various other issues and solutions, but I want to discuss locking down core plugins in the super pom _for_ 2.0 _only_. Normally we get into some large protracted discussions about better solutions and drawbacks/benefits of them, meanwhile the users suffer the wrath of auto plugin updates. Considering the amount of time I spent writing the enforcer requirePluginVersions rule, you can safely assume you don't need to convince me that the _right_ way is to lock them down in your poms. I already believe that. I also think that there is probably a better solution, whether it's plugin packs (which I don't agree with at this point) or something else. We can agree that whatever else it is that may be done will come in 2.1 and for a large portion of users 2.1 in production is a long way off and we continue to suffer bad press about the instability of Maven in the mean time. So I'd like to put those discussions aside for now and simply discuss the ramifications of defaulting the core plugin versions in the super pom in 2.0
Re: Plugin Versions in the Super pom
On 9-Feb-08, at 8:49 AM, Aaron Metzger wrote: Brian E. Fox wrote: We advertise the hell out of it and people will discover it as they have a problem that they resolve, can migrate to it as an upgrade process in their company environments and we don't screw someone over with our benevolent power. I think the biggest beef people have is that we are unstable by default. I don't think that requiring some action to get the versions locked is really going to help much. Otherwise we just continue to advertise the hell out of locking down your versions in the pom (which hasn't been working). --Brian A tiny inexperienced voice from the user side of things chiming in here... For me, I am completely aware that I want to lock *everything* down (including plugins) to have reproducible builds. So marketing, advertising, pleading with us, educating us is not the issue. The problem is not knowing or being able to keep up with the list of what combination of plugins and maven versions work well together. Whether or not the list of plugin versions is in the super POM is not the isue for me. It is the wisdom and experience of the person who would make the choices of which versions of the plugins to put in that default list that is the real value. In general I don't want to have to make those choices for every plugin -- just the occasional exception for when I really need some new feature or old compatibility. Either of two approaches would satisfy me: 1) Benevolent dictators strongly suggest the list of plugin versions which are thought to be stable together and that is in the super POM or I just cut-n-paste the suggested list in there myself from the web site. The code in the enforcer plugin can actually extract the versions that were used as part of a build so we could turn this into something people could use. John has also been working on a lifecycle plugin which displays the information about the lifecycle which means we could extract the information from that too and make a descriptor. So we can test different combinations of plugins as they are released and give those combinations to users in some controlled way. 2) I just go ahead and try my build process using all the latest plugin versions (current default behavior) and then when I see that they all work together have some mechanism to freeze the list and have the current versions (whatever they are) automatically written into my POM without me having to sort through and figure out what the versions are and manually insert them into the POM. I would want to be able to freeze the list not just at release time but at any arbitrary time to stabilize the development environment for my team. Thanks. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - 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 -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plugin Versions in the Super pom
Could we add some SHORT meta-data in the POM to point to a maven superPOM version ? By default, use the running maven superPOM, but when set, use the expected superPOM. Based on this, we could build with maven 2.0.10 a project designed with maven 2.0.9 superPOM. Nico. 2008/2/9, Brian E. Fox [EMAIL PROTECTED]: I have to change my vote to -1 : Current maven behavior introduces some issues when plugin version is not set. Many users got errors with this and learned to use version. Having maven super-POM set plugin version will make the build depend on maven version used. Compare this change to the current behavior. People simply are not locking them down either because they don't know or they don't want to make huge xmls. (remember I still think locking them down is the right way to do it, but apparently the majority of the users don't/won't). So if we do nothing, they are just as likely to have un-reproducible builds with a later version of maven. And worse, they potentially break across developers because their machines have different versions and it changes suddenly without them having any interaction. What you point out is definitely a risk, but I see it as less harmful than the current method. --Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plugin Versions in the Super pom
On Sat, 2008-02-09 at 09:04 -0800, Jason van Zyl wrote: On 9-Feb-08, at 8:49 AM, Aaron Metzger wrote: For me, I am completely aware that I want to lock *everything* down (including plugins) to have reproducible builds. So marketing, advertising, pleading with us, educating us is not the issue. The code in the enforcer plugin can actually extract the versions that were used as part of a build so we could turn this into something people could use. John has also been working on a lifecycle plugin which displays the information about the lifecycle which means we could extract the information from that too and make a descriptor. So we can test different combinations of plugins as they are released and give those combinations to users in some controlled way. I think the idea of specifying versions in the super pom is pointless. Stability for a given release of maven is not particularly useful when many users are using different versions of maven to build something. It would be much more useful for maven 2.0.9 to simply *warn* when a plugin is found without a version. That's better than trying to advertise best practice via the maven website. Better yet, have it fail the build unless some kind of override option is present on the command-line. Isn't that part of what the enforcer plugin actually does? If so, then why not make that a default plugin in maven 2.0.9, ie bind it to an appropriate phase by default? It would be also nice for maven to have the ability to dump the versions of stuff it uses for any particular build, then allow later runs of maven to accept that dump-file as input to set the versions. That's a quick-fix for people who find 2.0.9 reporting errors on their builds due to incomplete dependency versioning. I've personally never encountered a situation where one version of a plugin would not work with some other version of a different plugin. What I have found difficult is determining whether things *have* all been locked down or whether something has been missed. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plugin Versions in the Super pom
On 2/10/08, Jason van Zyl [EMAIL PROTECTED] wrote: You're asking for a far more complicated solutions to be implemented which generally aren't much more helpful. You're also conflating the solution with what people should do and what they should actually be doing. Yes, people should use versions for their plugins, but in the absence of that putting the versions in the POM is the easiest solution to provide the most stability, in most cases. Well said. I'm really excited to see this discussion and the generally positive support for the proposal. Providing stable, repeatable builds out of the box is such an important feature in a build tool. As I understand it, you can still override the plugin versions in your own POMs, but for the vast Maven newbie public, this change would go a long ways to meeting expectations. [shameless bribe] Make this change in 2.x and I'll fix all the issues remaining for http://jira.codehaus.org/browse/MNG-3379 ... :) Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plugin Versions in the Super pom
I think the idea of specifying versions in the super pom is pointless. Stability for a given release of maven is not particularly useful when many users are using different versions of maven to build something. I think it's common sense that the proposed lock down in the super POM is not the final solution and was not intended as such. Reproducible builds require the user himself to lock the plugin versions in his own (corporate) POM, nobody else can do this. The changes to the super POM are all about improving (not solving) the current situation for Maven 2.0.x. If we can agree on the assumption that there are less different versions of Maven in use than local repositories existent among the developers, the additions in the super POM help to improve build reproducibility. It would be much more useful for maven 2.0.9 to simply *warn* when a plugin is found without a version. That's better than trying to advertise best practice via the maven website. Better yet, have it fail the build unless some kind of override option is present on the command-line. For the sake of backward-compatibility within the 2.0.x development line, one surely would not want to break the build here. What I have found difficult is determining whether things *have* all been locked down or whether something has been missed. You could run mvn clean deploy site-deploy -U and grep for checking for updates in the log output. Regards, Benjamin Bentmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plugin Versions in the Super pom
On 9-Feb-08, at 12:31 PM, Benjamin Bentmann wrote: I think the idea of specifying versions in the super pom is pointless. Stability for a given release of maven is not particularly useful when many users are using different versions of maven to build something. I think it's common sense that the proposed lock down in the super POM is not the final solution and was not intended as such. Exactly, it's a practical means to a short term end that helps with the average, new, inexperienced user. Reproducible builds require the user himself to lock the plugin versions in his own (corporate) POM, nobody else can do this. The changes to the super POM are all about improving (not solving) the current situation for Maven 2.0.x. If we can agree on the assumption that there are less different versions of Maven in use than local repositories existent among the developers, the additions in the super POM help to improve build reproducibility. It would be much more useful for maven 2.0.9 to simply *warn* when a plugin is found without a version. That's better than trying to advertise best practice via the maven website. Better yet, have it fail the build unless some kind of override option is present on the command-line. For the sake of backward-compatibility within the 2.0.x development line, one surely would not want to break the build here. What I have found difficult is determining whether things *have* all been locked down or whether something has been missed. You could run mvn clean deploy site-deploy -U and grep for checking for updates in the log output. Regards, Benjamin Bentmann - 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 -- Selfish deeds are the shortest path to self destruction. -- The Seven Samuari, Akira Kirosawa - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plugin Versions in the Super pom
On 9-Feb-08, at 12:33 PM, Don Brown wrote: On 2/10/08, Jason van Zyl [EMAIL PROTECTED] wrote: You're asking for a far more complicated solutions to be implemented which generally aren't much more helpful. You're also conflating the solution with what people should do and what they should actually be doing. Yes, people should use versions for their plugins, but in the absence of that putting the versions in the POM is the easiest solution to provide the most stability, in most cases. Well said. I'm really excited to see this discussion and the generally positive support for the proposal. Providing stable, repeatable builds out of the box is such an important feature in a build tool. As I understand it, you can still override the plugin versions in your own POMs, but for the vast Maven newbie public, this change would go a long ways to meeting expectations. This makes the situation better, but still has the potential to hose people. It's just less likely that some new users will start with 2.0.x, then quickly switch to 2.0.x+1 and get nailed. This doesn't promote a best practice but goes a step toward keeping the shot gun out of peoples' mouthes. What I will push for in 2.1 is a version requirement in the POM. From the command line you'll get the latest. But this is something we never should have done, and the auto upgrade was also a mistake. But in the short term the downside is acceptable and it's very easy to do. [shameless bribe] Make this change in 2.x and I'll fix all the issues remaining for http://jira.codehaus.org/browse/MNG-3379 ... :) For the 2.0.x I'm fine with anything there, but for the the separated maven-artifact I have asked Greg/Jan (Jetty folks) to help create a connector using the Jetty client library that would be optimal for use with Maven. They probably have a tad more experience with HTTP then any of us and I'm hopeful they come up with an optimal long term strategy. Don - 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 -- In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plugin Versions in the Super pom
On 9-Feb-08, at 11:55 AM, simon wrote: On Sat, 2008-02-09 at 09:04 -0800, Jason van Zyl wrote: On 9-Feb-08, at 8:49 AM, Aaron Metzger wrote: For me, I am completely aware that I want to lock *everything* down (including plugins) to have reproducible builds. So marketing, advertising, pleading with us, educating us is not the issue. The code in the enforcer plugin can actually extract the versions that were used as part of a build so we could turn this into something people could use. John has also been working on a lifecycle plugin which displays the information about the lifecycle which means we could extract the information from that too and make a descriptor. So we can test different combinations of plugins as they are released and give those combinations to users in some controlled way. I think the idea of specifying versions in the super pom is pointless. Stability for a given release of maven is not particularly useful when many users are using different versions of maven to build something. It would be much more useful for maven 2.0.9 to simply *warn* when a plugin is found without a version. That's what the enforcer plugin can do. Don't expect people to know what it is, or what it does initially. You are now a seasoned user, and probably version everything. This solution is not for you. For 2.1 we could make them mandatory, this is a solution to help the inexperienced Maven user not get bit in the ass. This does not negate: - creating better documentation to get people to lock down their versions - creating better tools to present snippets of version information But who is going to create those tools? This is an easy fix to provide a better situation. Not an ideal situation but I see no downside for the average user. That's better than trying to advertise best practice via the maven website. Better yet, have it fail the build unless some kind of override option is present on the command-line. Isn't that part of what the enforcer plugin actually does? If so, then why not make that a default plugin in maven 2.0.9, ie bind it to an appropriate phase by default? It would be also nice for maven to have the ability to dump the versions of stuff it uses for any particular build, then allow later runs of maven to accept that dump-file as input to set the versions. That's a quick-fix for people who find 2.0.9 reporting errors on their builds due to incomplete dependency versioning. I've personally never encountered a situation where one version of a plugin would not work with some other version of a different plugin. What I have found difficult is determining whether things *have* all been locked down or whether something has been missed. Regards, Simon - 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 -- What matters is not ideas, but the people who have them. Good people can fix bad ideas, but good ideas can't save bad people. -- Paul Graham - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Plugin Versions in the Super pom
I created a jira for this and will attempt a scan through existing issues to see how many might be related to this. So far we've started to go off on tangential other ideas which is good for 2.1, but I haven't seen any showstopper reason why this could actually hurt anyone. -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Saturday, February 09, 2008 2:26 PM To: Maven Developers List Subject: Re: Plugin Versions in the Super pom On 9-Feb-08, at 12:31 PM, Benjamin Bentmann wrote: I think the idea of specifying versions in the super pom is pointless. Stability for a given release of maven is not particularly useful when many users are using different versions of maven to build something. I think it's common sense that the proposed lock down in the super POM is not the final solution and was not intended as such. Exactly, it's a practical means to a short term end that helps with the average, new, inexperienced user. Reproducible builds require the user himself to lock the plugin versions in his own (corporate) POM, nobody else can do this. The changes to the super POM are all about improving (not solving) the current situation for Maven 2.0.x. If we can agree on the assumption that there are less different versions of Maven in use than local repositories existent among the developers, the additions in the super POM help to improve build reproducibility. It would be much more useful for maven 2.0.9 to simply *warn* when a plugin is found without a version. That's better than trying to advertise best practice via the maven website. Better yet, have it fail the build unless some kind of override option is present on the command-line. For the sake of backward-compatibility within the 2.0.x development line, one surely would not want to break the build here. What I have found difficult is determining whether things *have* all been locked down or whether something has been missed. You could run mvn clean deploy site-deploy -U and grep for checking for updates in the log output. Regards, Benjamin Bentmann - 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 -- Selfish deeds are the shortest path to self destruction. -- The Seven Samuari, Akira Kirosawa - 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: Plugin Versions in the Super pom
On 9-Feb-08, at 9:32 PM, Ralph Goers wrote: In my world I require a reproduceable build. Typically, that means a specific release would have to be built using a specific version of Maven. Any attempt to build it at a later time would need to still use that release. This isn't just because of default versions of plugins but because the behavior of Maven itself might have changed. Now, while I think it is great to have default versions of plugins, when push comes to shove I won't really care. Just like I will use my own managed dependency specifications to control dependency versions I would also recommend explicitly controlling the plugin versions used. I'm not a big fan of letting Maven dynamically pick versions of anything as it leads to a build which can't be reliably recreated. So if this proposal means that each version of Maven hard-wires default versions of plugins - but that those plugin versions can be overridden then I definitely agree that that is the correct way to go. That's exactly what it means. Ralph nicolas de loof wrote: I have to change my vote to -1 : Current maven behavior introduces some issues when plugin version is not set. Many users got errors with this and learned to use version. Having maven super-POM set plugin version will make the build depend on maven version used. Simple scenario : I create a project with maven 2.0.9, wich introduces superPOM with versionned plugins. My build is reproductible even when new plugins are released. This DOESN't learn me best-practices about plugins versionning. Latter I come back to this project for maintenance with maven 2.0.11, that I expect to be backward compatible. As not beeing a hacker I don't even know what version of maven I'm using, simply run some eclipse integration (maybe we will have some one day or the other) ... and the project gets broken as 2.0.11 superPOM doesn't set the same plugins ! I got such scenario in REAL-WORLD projects using maven1 : maintenance developers (maven newbees) had errors when building the project ... because maven 1.1 was installed as default on the developer environment, and the project used maven 1.0.2 with some uncompatible plugins. - 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 -- We know what we are, but know not what we may be. -- Shakespeare - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plugin Versions in the Super pom
In my world I require a reproduceable build. Typically, that means a specific release would have to be built using a specific version of Maven. Any attempt to build it at a later time would need to still use that release. This isn't just because of default versions of plugins but because the behavior of Maven itself might have changed. Now, while I think it is great to have default versions of plugins, when push comes to shove I won't really care. Just like I will use my own managed dependency specifications to control dependency versions I would also recommend explicitly controlling the plugin versions used. I'm not a big fan of letting Maven dynamically pick versions of anything as it leads to a build which can't be reliably recreated. So if this proposal means that each version of Maven hard-wires default versions of plugins - but that those plugin versions can be overridden then I definitely agree that that is the correct way to go. Ralph nicolas de loof wrote: I have to change my vote to -1 : Current maven behavior introduces some issues when plugin version is not set. Many users got errors with this and learned to use version. Having maven super-POM set plugin version will make the build depend on maven version used. Simple scenario : I create a project with maven 2.0.9, wich introduces superPOM with versionned plugins. My build is reproductible even when new plugins are released. This DOESN't learn me best-practices about plugins versionning. Latter I come back to this project for maintenance with maven 2.0.11, that I expect to be backward compatible. As not beeing a hacker I don't even know what version of maven I'm using, simply run some eclipse integration (maybe we will have some one day or the other) ... and the project gets broken as 2.0.11 superPOM doesn't set the same plugins ! I got such scenario in REAL-WORLD projects using maven1 : maintenance developers (maven newbees) had errors when building the project ... because maven 1.1 was installed as default on the developer environment, and the project used maven 1.0.2 with some uncompatible plugins. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Plugin Versions in the Super pom
So if this proposal means that each version of Maven hard-wires default versions of plugins - but that those plugin versions can be overridden then I definitely agree that that is the correct way to go. This is exactly what I'm proposing. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plugin Versions in the Super pom
Could the enforcer plugin still warn about missing plugins version if they are set in the super POM ? Nico 2008/2/10, Ralph Goers [EMAIL PROTECTED]: In my world I require a reproduceable build. Typically, that means a specific release would have to be built using a specific version of Maven. Any attempt to build it at a later time would need to still use that release. This isn't just because of default versions of plugins but because the behavior of Maven itself might have changed. Now, while I think it is great to have default versions of plugins, when push comes to shove I won't really care. Just like I will use my own managed dependency specifications to control dependency versions I would also recommend explicitly controlling the plugin versions used. I'm not a big fan of letting Maven dynamically pick versions of anything as it leads to a build which can't be reliably recreated. So if this proposal means that each version of Maven hard-wires default versions of plugins - but that those plugin versions can be overridden then I definitely agree that that is the correct way to go. Ralph nicolas de loof wrote: I have to change my vote to -1 : Current maven behavior introduces some issues when plugin version is not set. Many users got errors with this and learned to use version. Having maven super-POM set plugin version will make the build depend on maven version used. Simple scenario : I create a project with maven 2.0.9, wich introduces superPOM with versionned plugins. My build is reproductible even when new plugins are released. This DOESN't learn me best-practices about plugins versionning. Latter I come back to this project for maintenance with maven 2.0.11, that I expect to be backward compatible. As not beeing a hacker I don't even know what version of maven I'm using, simply run some eclipse integration (maybe we will have some one day or the other) ... and the project gets broken as 2.0.11 superPOM doesn't set the same plugins ! I got such scenario in REAL-WORLD projects using maven1 : maintenance developers (maven newbees) had errors when building the project ... because maven 1.1 was installed as default on the developer environment, and the project used maven 1.0.2 with some uncompatible plugins. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Plugin Versions in the Super pom
Yes, I had to walk the poms in the rule to see if the version was specified anywhere. (the model in project always has versions filled in, even if they aren't actually specified in the poms.) The code stops walking up the pom tree when there is no parent specified and it doesn't look in the super pom. The net result is that if you haven't locked down your versions and you use the requirePluginVersions rule, then it will fail just like it does today. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of nicolas de loof Sent: Saturday, February 09, 2008 11:05 PM To: Maven Developers List; [EMAIL PROTECTED] Subject: Re: Plugin Versions in the Super pom Could the enforcer plugin still warn about missing plugins version if they are set in the super POM ? Nico 2008/2/10, Ralph Goers [EMAIL PROTECTED]: In my world I require a reproduceable build. Typically, that means a specific release would have to be built using a specific version of Maven. Any attempt to build it at a later time would need to still use that release. This isn't just because of default versions of plugins but because the behavior of Maven itself might have changed. Now, while I think it is great to have default versions of plugins, when push comes to shove I won't really care. Just like I will use my own managed dependency specifications to control dependency versions I would also recommend explicitly controlling the plugin versions used. I'm not a big fan of letting Maven dynamically pick versions of anything as it leads to a build which can't be reliably recreated. So if this proposal means that each version of Maven hard-wires default versions of plugins - but that those plugin versions can be overridden then I definitely agree that that is the correct way to go. Ralph nicolas de loof wrote: I have to change my vote to -1 : Current maven behavior introduces some issues when plugin version is not set. Many users got errors with this and learned to use version. Having maven super-POM set plugin version will make the build depend on maven version used. Simple scenario : I create a project with maven 2.0.9, wich introduces superPOM with versionned plugins. My build is reproductible even when new plugins are released. This DOESN't learn me best-practices about plugins versionning. Latter I come back to this project for maintenance with maven 2.0.11, that I expect to be backward compatible. As not beeing a hacker I don't even know what version of maven I'm using, simply run some eclipse integration (maybe we will have some one day or the other) ... and the project gets broken as 2.0.11 superPOM doesn't set the same plugins ! I got such scenario in REAL-WORLD projects using maven1 : maintenance developers (maven newbees) had errors when building the project ... because maven 1.1 was installed as default on the developer environment, and the project used maven 1.0.2 with some uncompatible plugins. - 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: Plugin Versions in the Super pom
I'm pretty much +1 Another behavior that would change is if I build and install a plugin in my local repo, it won't be used. I'd have to explicitly set it in the pom. On Feb 8, 2008 4:41 PM, Brian E. Fox [EMAIL PROTECTED] wrote: I know it's been discussed before in the context of various other issues and solutions, but I want to discuss locking down core plugins in the super pom _for_ 2.0 _only_. Normally we get into some large protracted discussions about better solutions and drawbacks/benefits of them, meanwhile the users suffer the wrath of auto plugin updates. Considering the amount of time I spent writing the enforcer requirePluginVersions rule, you can safely assume you don't need to convince me that the _right_ way is to lock them down in your poms. I already believe that. I also think that there is probably a better solution, whether it's plugin packs (which I don't agree with at this point) or something else. We can agree that whatever else it is that may be done will come in 2.1 and for a large portion of users 2.1 in production is a long way off and we continue to suffer bad press about the instability of Maven in the mean time. So I'd like to put those discussions aside for now and simply discuss the ramifications of defaulting the core plugin versions in the super pom in 2.0 only. I see two main benefits: 1. Those who have followed best practice and locked their versions down will not be affected by this at all. The normal inheritance rules will apply, and we'll put these versions into the pluginManagement section of the super pom. 2. Those who have not locked their versions down will only be affected by gaining stability in between maven releases. If they want a new plugin before the next Maven release, they will have to follow the best practices and lock their version down to the new version. (this actually informs people and encourages them to learn how to do that...but when _they_ are ready to do it because they are motivated to grab a new release, not when they least expect it because we pushed out a plugin that broke their build) 3. The change is very simple, can be done quickly and has little harm of creating more problems. The only drawback I can see is that it lulls people into a false sense of security because _less_ plugins auto update Not all of them. Certainly we won't lock down every plugin in existence and those plugins will still be subjected to the auto update. Again, I'm not suggesting we solve the world here, but this is a simple step forward to reduce the impact of one of the most frequent complaints of the users. If you can think of some serious drawbacks to this approach, speak now for forever hold your peace ;-) --Brian -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plugin Versions in the Super pom
On 8-Feb-08, at 4:52 PM, Carlos Sanchez wrote: I'm pretty much +1 Another behavior that would change is if I build and install a plugin in my local repo, it won't be used. I'd have to explicitly set it in the pom. Sure, but that's a minor inconvenience for us developing plugins in the default lifecycle, but for the user if it helps then it's a low- tech solution that will help folks. I agree with Brian. People are miseducated and that's our fault. The new version of the enforcer plugin helps, but if this helps stabilize things for those who haven't yet figured out that putting versions on your plugins is a good idea then so be it. On Feb 8, 2008 4:41 PM, Brian E. Fox [EMAIL PROTECTED] wrote: I know it's been discussed before in the context of various other issues and solutions, but I want to discuss locking down core plugins in the super pom _for_ 2.0 _only_. Normally we get into some large protracted discussions about better solutions and drawbacks/benefits of them, meanwhile the users suffer the wrath of auto plugin updates. Considering the amount of time I spent writing the enforcer requirePluginVersions rule, you can safely assume you don't need to convince me that the _right_ way is to lock them down in your poms. I already believe that. I also think that there is probably a better solution, whether it's plugin packs (which I don't agree with at this point) or something else. We can agree that whatever else it is that may be done will come in 2.1 and for a large portion of users 2.1 in production is a long way off and we continue to suffer bad press about the instability of Maven in the mean time. So I'd like to put those discussions aside for now and simply discuss the ramifications of defaulting the core plugin versions in the super pom in 2.0 only. I see two main benefits: 1. Those who have followed best practice and locked their versions down will not be affected by this at all. The normal inheritance rules will apply, and we'll put these versions into the pluginManagement section of the super pom. 2. Those who have not locked their versions down will only be affected by gaining stability in between maven releases. If they want a new plugin before the next Maven release, they will have to follow the best practices and lock their version down to the new version. (this actually informs people and encourages them to learn how to do that...but when _they_ are ready to do it because they are motivated to grab a new release, not when they least expect it because we pushed out a plugin that broke their build) 3. The change is very simple, can be done quickly and has little harm of creating more problems. The only drawback I can see is that it lulls people into a false sense of security because _less_ plugins auto update Not all of them. Certainly we won't lock down every plugin in existence and those plugins will still be subjected to the auto update. Again, I'm not suggesting we solve the world here, but this is a simple step forward to reduce the impact of one of the most frequent complaints of the users. If you can think of some serious drawbacks to this approach, speak now for forever hold your peace ;-) --Brian -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - 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 -- A party which is not afraid of letting culture, business, and welfare go to ruin completely can be omnipotent for a while. -- Jakob Burckhardt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
