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" <[email protected]> > > > To > "Maven Users List" <[email protected]> > 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]
