Is there a philosophical reason why release plugin shouldn't do that on behalf of the users?
Maven makes alot of things simpler and pleasant for you (i.e., transitive dependencies, lifecycles management etc..) and then there are occasional things like this that makes you wonder why would I have to care? Most of the time users don't really care if he/she run sure fire 2.3, complier plugin 2.0.2, jar plugin 2.1 and countless other plugins that are magically invoked to make the build works. Explicitly specifying all the plugins (let alone its version) is definitely not a fun thing to do. The trouble with shared parent pom is that, there will be one per logical set of deliverable projects. So in our environment, there is one poping up all the time. Even if we can create our own super pom and store it some where in SVN, maven won't know how to tag the custom super pom that is outside it's project. Personally, I think release plugin should have some of the enforcer features built in. If enforcer is the way to go, then I think there needs to be a big disclaimer in the release plugin or Maven FAQ saying that you must use enforcer to ensure repeatable build across releases. Cheers, rOnn c. "Brett Porter" <[EMAIL PROTECTED]> 12/10/2007 11:13 AM Please respond to "Maven Users List" <users@maven.apache.org> To "Maven Users List" <users@maven.apache.org> cc Subject Re: Backwards incompatibility with 2.0.8? It is a best practice - in a shared parent POM so that you don't need to do it frequently. The release plugin doesn't do it, but the enforcer plugin can be used to ensure that you have. Cheers, Brett On 10/12/2007, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Right, thanks for the explanation. > > Explicitly specifying the plugin version would help in this particular > case but would we then need explictly declare every single plugin in the > project to guard against future problem? i.e., clean, compiler, deployer, > install, jar, war etc... would you then recommending this as the best > practice? Surely this will lead to a very large pom.xml. I supposed, the > release plugin can do this work, but does it currently do this ? > > rOnn c. > > > > > > > > Michael McCallum <[EMAIL PROTECTED]> > 12/10/2007 10:41 AM > Please respond to > "Maven Users List" <users@maven.apache.org> > > > To > "Maven Users List" <users@maven.apache.org> > cc > > Subject > Re: Backwards incompatibility with 2.0.8? > > > > > > > its just coincidental that surefire 2.3.1 was released at the same time as > > 2.0.8... > > if you specify surefire 2.3 or less in you pluginManagement then the tests > > will start working again... of course its best practice to specify plugin > versions anyway so magic upgrades don't break things > > On Mon, 10 Dec 2007 12:30:25 [EMAIL PROTECTED] wrote: > > We were using maven 2.0.6 in a team with Artifactory as a proxy. > > > > I then upgrade my environment to 2.0.8. A whole bunch of new plugins get > > fetched. > > > > Other people were using 2.0.6 but it appears that they also get a whole > > heap of new plugins. > > > > As a result, test cases in another project which had worked before now > > failed for people running 2.0.6. It appears that the problem is with > > classpath ordering - for some reason with 2.0.6 and the new bunch of > > plugins, src/main/resources gets picked up before src/test/resources and > > so it doesn't load the resources for test cases. > > > > So what happens now is that everyone has to abandon 2.0.6 to 2.0.8. > > > > Can someone offer any explanation how this could happen? > > > > It concerns me that someone running 2.0.6 would now be forced to move to > > 2.0.8 simply because I decided to upgrade to 2.0.8 in my own environment > > and project? Is the automatic plugin update a problem here? > > > > I don't understand how automatic plugin update works but how would one > > guarantee repeatable builds ? esp with the releases that have been > tagged > > and potentailly checked out for build later. > > > > > > rOnn c. > > ###################################################################### > > DISCLAIMER: > > This email and any attachment may contain confidential information. > > If you are not the intended recipient you are not authorized to copy > > or disclose all or any part of it without the prior written consent > > of Toyota. > > > > Opinions expressed in this email and any attachments are those of the > > sender and not necessarily the opinions of Toyota. > > Please scan this email and any attachment(s) for viruses. > > Toyota does not accept any responsibility for problems caused by > > viruses, whether it is Toyota's fault or not. > > ###################################################################### > > > > -- > Michael McCallum > Enterprise Engineer > mailto:[EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > ###################################################################### > DISCLAIMER: > This email and any attachment may contain confidential information. > If you are not the intended recipient you are not authorized to copy > or disclose all or any part of it without the prior written consent > of Toyota. > > Opinions expressed in this email and any attachments are those of the > sender and not necessarily the opinions of Toyota. > Please scan this email and any attachment(s) for viruses. > Toyota does not accept any responsibility for problems caused by > viruses, whether it is Toyota's fault or not. > ###################################################################### > -- Brett Porter Blog: http://www.devzuz.org/blogs/bporter/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ###################################################################### DISCLAIMER: This email and any attachment may contain confidential information. If you are not the intended recipient you are not authorized to copy or disclose all or any part of it without the prior written consent of Toyota. Opinions expressed in this email and any attachments are those of the sender and not necessarily the opinions of Toyota. Please scan this email and any attachment(s) for viruses. Toyota does not accept any responsibility for problems caused by viruses, whether it is Toyota's fault or not. ######################################################################
