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. ######################################################################
