Fwd: Backwards incompatibility with 2.0.8?

[Brett Porter <br...@gmail.com>]

Guys,

This is the issue I was referring to - looks like just the classpath
ordering, and so can just be documented.

Or is that overlooking a potential issue with 2.3.1 on 2.0.6?

Cheers,
Brett

---------- Forwarded message ----------
From: Ronn.Chinowutthichai@toyota.com.au <Ro...@toyota.com.au>
Date: 10 Dec 2007 16:45
Subject: Re: Backwards incompatibility with 2.0.8?
To: Maven Users List <us...@maven.apache.org>
Cc: Maven Users List <us...@maven.apache.org>


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" <br...@gmail.com>
12/10/2007 11:24 AM
Please respond to
"Maven Users List" <us...@maven.apache.org>


To
"Maven Users List" <us...@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, Ronn.Chinowutthichai@toyota.com.au
<Ro...@toyota.com.au> 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" <br...@gmail.com>
> 12/10/2007 10:42 AM
> Please respond to
> "Maven Users List" <us...@maven.apache.org>
>
>
> To
> "Maven Users List" <us...@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 <gh...@apache.org> 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 Ronn.Chinowutthichai@toyota.com.au 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:gholam@apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
>
> --
> Brett Porter
> Blog: http://www.devzuz.org/blogs/bporter/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
> ######################################################################
> 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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org



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