In Surefire 2.4, we stopped having surefire-booter depend directly on plexus-archiver. We did that partly to workaround MSHADE-9 and partly to simply reduce the number of dependencies in surefire-booter (which unfortunately has to be in the classpath of the launched tests).
Our dependency on plexus-archiver was minimal: all we needed to do was write out an empty jar with a manifest in it. I attempted to copy the relevant code out of plexus-archiver and use just a few lines in surefire-booter in a simple class called ManifestJarWriter.
http://svn.apache.org/viewvc/maven/surefire/trunk/surefire-booter/src/main/java/org/apache/maven/surefire/booter/ManifestJarWriter.java http://tinyurl.com/2adoec
In SUREFIRE-445, it was pointed out that there's some bugs in that code in Surefire (for example, it doesn't include a ManifestVersion); a patch is included. But the patch also does something interesting: it basically guts ManifestJarWriter, in favor of a class that I didn't happen to know about: java.util.jar.Manifest.
I like the idea of this change (why maintain our own code to write manifests?) but it makes me suspicious... Surely there was some reason why plexus-archiver had reinvented the wheel here; probably to fix a bug or something.
Is this just a case where we've accidentally reinvented a class that's been available in the JDK since 1.2? Is there something else more complex going on here that I don't quite understand? Should I use java.util.jar.Manifest, or prefer to maintain the logic myself?
-Dan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
