I've worked out what happened. Surefire 2.3.1 is not in the central repository yet but apparantly it has been tagged (http://jira.codehaus.org/browse/MNG-3118).
Last Friday, I've downloaded maven source and build it on my local machine (and added apache snapshot into Artifactory). As a result, surefire 2.3.1-SNAPSHOT got into our Artifactory. This is what I've found. Maven 2.0.6 + surefire 2.3 works. Maven 2.0.6 + surefire 2.3.1-SNAPSHOT doesn't work. Maven 2.0.8 + surefire 2.3 doesn't work Maven 2.0.8 + surefire 2.3.1-SNAPSHOT works. I'm not sure what differences there are in surefire 2.3.1-SNAPSHOT and 2.3.1. I can't find surefire 2.3.1 anywhere so I'll wait and see. Thanks for your help. Cheers, rOnn c. "Brett Porter" <[EMAIL PROTECTED]> 12/10/2007 11:24 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? Your act of upgrading certainly can't have broken his environment :) There are two possibilities: a) something changed in a surefire snapshot. This is possible as its under active development, though I'm not sure if new snapshots are being deployed regularly. b) a test was added to your environment that relied on the classpath ordering. b) still sounds like the most likely based on your original message - note that 2.0.6 always had main-first ordering, while 2.0.8 has test-first ordering. If you have a sample case where 2.0.6 + surefire 2.3 succeeds and 2.0.6 + 2.3.1 fails, please file it in the surefire JIRA. Otherwise, I would look at the test cases as above. Note you can also use the enforcer to force a Maven version to require people to upgrade to 2.0.8 - consistency is likely to give you less headaches, though I can understand that this is not something you would want to jump to quite so soon perhaps given it is a recent release. I'm still using 2.0.7 myself :) Cheers, Brett On 10/12/2007, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Ok, but our problem is not a simple backward compatibility. > > I was working on project A on my machine. I upgraded to 2.0.8. Nothing > breaks here but it it break then fair enough. > > A colleauge was working on project B and still using 2.0.6. > > Some how my action of upgrading to 2.0.8 in my machine has cause his build > environment to break in his machine. > > Both build machine uses surefire 2.3.1-SNAPSHOT. So perhaps surefure 2.3.1 > doesn't work with Maven 2.0.6 ? > > > rOnn c. > > > > > > > "Brett Porter" <[EMAIL PROTECTED]> > 12/10/2007 10:42 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? > > > > > > > No, it's because 2.0.8 is not backwards compatible with 2.0.6, as > documented in the release notes. > > On 10/12/2007, Michael McCallum <[EMAIL PROTECTED]> wrote: > > 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] > > > > > > > -- > 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. > ###################################################################### > -- 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. ######################################################################