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#seg7
http://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