This is a long e-mail, so I divided it into parts.
Summary: I think we're ready to release 2.3.1, because I can't reproduce
"regression" SUREFIRE-347, the only bug targeted for 2.3.1. I was able to
reproduce a related bug SUREFIRE-334, and was able to fix it using
maven-shade-plugin alpha-14-SNAPSHOT (even though MSHADE-9 isn't fixed
yet). If we go ahead and release maven-shade-plugin alpha-14-SNAPSHOT, we
can release Surefire 2.4 as well (or instead).
Part 1: The problem with plexus dependency conflicts
Part 2: Testing the problem
Part 3: How I fixed the problem in trunk
1) The problem with plexus dependency conflicts
A couple of weeks ago I did a bunch of work with an eye toward getting
Surefire 2.4 into a state where it could be released. The main remaining
issue was the problem of plexus dependency conflicts. In some cases,
Surefire would add its own plexus dependencies into the classpath of the
tests; if the application under test depended on some other version of
those plexus dependencies, you'd get some gnarly errors that were
difficult to diagnose.
Two JIRA issues were associated with this problem, both of which were
originally filed against Surefire 2.3.1: SUREFIRE-347 [regression: plexus
is not properly isolated] and SUREFIRE-334 [useSystemClassLoader
introduces dependencies]. SUREFIRE-332 [remove dependency on
plexus-utils, use a split out cli package] was another related suggestion,
not targeted for 2.3.1.
(There was also SUREFIRE-335 [forkMode = none is incompatible with
useSystemClassLoader = true], but that one didn't make as much sense.
I've marked it "Won't Fix.")
A few days ago, Mauro suggested that we release Surefire 2.3.1; I'd
pointed out that -347 and -334 were still targeted for 2.3.1 and that we'd
probably want to fix them before releasing 2.3.1. Right now only -347,
the regression, is targeted for 2.3.1.
2) Testing the problem
I made a simple "plexus-conflict" integration test. (The Surefire
integration tests are all full Maven projects that we fork a separate
process to run, just like the Core tests.)
In the test project, I depended on plexus-utils 1.0.4 and extended the
Commandline object. In 1.0.4, Commandline had a protected "envVars"
Vector; in 1.4.x, envVars is a Map. Surefire depends on plexus-utils
1.4.8; if 1.4.8 were inserted on the classpath instead of the expected
1.0.4, you'd get an error.
Interestingly, when I ran the test in the default mode
(useSystemClassLoader=false) I found that the test passed, just fine, in
both Surefire 2.3 and also Surefire 2.4 Trunk. I think that means that I
couldn't reproduce the regression bug SUREFIRE-347, the only bug targeted
for Surefire 2.3.1!
I was able to reproduce SUREFIRE-334 with useSystemClassLoader=true in
2.4. (In 2.3 useSystemClassLoader=true utterly failed, even on the
simplest integration test project; I don't think it works at all in 2.3.)
3) How I fixed the problem in trunk
The way I had imagined we'd fix these issues was to use maven-shade-plugin
to relocate the packages for all Surefire dependencies. (It only had
three dependencies: plexus-archiver, plexus-utils, and commons-lang.)
Unfortunately, when I tried shade a couple of weeks ago, I bumped straight
into MSHADE-9 [failure to shade/relocate plexus-archiver (interfaces not
properly relocated)] which blocked my use of shade.
However, our dependency on plexus-archiver was very minimal: all we were
doing was creating an empty jar with a MANIFEST.MF file with a
"Class-Path" attribute. So, with an eye toward simplifying things by
reducing dependencies, and also trying to work around MSHADE-9, I checked
in revision 602583, which ripped out our dependency on plexus-archiver,
replacing it with a single class that just creates a simple jar with a
manifest.
Luckily, with plexus-archiver ripped out, I was able to use
maven-shade-plugin alpha-14-SNAPSHOT to shade both of the remaining
dependencies (plexus-utils and commons-lang).
I think that means that if we release maven-shade-plugin
alpha-14, even without fixing MSHADE-9, we can release Surefire 2.4, which
would make me very happy. :-)
Thanks for reading!
-Dan
