Thanks to a tip from olamy I managed to get the test to pass with
1.0-alpha-10-SNAPSHOT (by excluding dependency on plexus-container-default
and then depending on it at provided scope).
I'm still curious to know what this change was needed for. I looked at
the diff here and it doesn't make a lot of sense to me; the test seems to
work without these changes.
http://fisheye.codehaus.org/browse/plexus/plexus-components/trunk/plexus-archiver/src/main/java/org/codehaus/plexus/archiver/jar/JarArchiver.java?ignore2=w&r1=4612&r2=7007&u=3#seg7http://tinyurl.com/32yx3s-Dan
Dan Fabulich wrote:
>
> Today I checked in an integration test for SUREFIRE-389
> (IncompatibleClassChangeError when useSystemClassLoader=true). You get an
> ICCE simply by running "mvn test -Dsurefire.useSystemClassLoader=true" on the
> quickstart archetype; it's pretty bad.
>
> The problem appears to be in the plexus-archiver. Last month in revision
> 588274 jdcasey bumped the version from 1.0-alpha-7 to 1.0-alpha-10-SNAPSHOT,
> apparently to "fix" useSystemClassLoader (???).
>
> But plexus-archiver:1.0-alpha-10-SNAPSHOT depends on
> plexus-container-default:1.0-alpha-15, in conflict with maven-2.0.7's
> plexus-container-default:1.0-alpha-9-stable-1.
>
> It appears that -archiver:-10-SNAPSHOT, expecting -container-default:-15, is
> getting -9-stable-1, and is throwing an ICCE.
>
> When I downgrade back to -archiver -7, everything seems to work fine
> (including my useSystemClassLoader integration test).
>
> I'm not really sure what bug jdcasey was addressing with revision 588274, but
> an ICCE can't possibly be an improvement over what was there before...?
>
> I presume jdcasey was fixing a real bug, though... Any idea what it was? How
> can we fix that bug without causing an ICCE?
>
> -Dan
>