John Plocher wrote: > Jim Walker wrote: >> We also understand the problem where several open source projects depend >> on older versions of Junit and don't plan to update their code to use >> the newer version. We felt it was best to start by porting the current >> version and revise it as new releases are made available. Then, look at >> adding additional older versions that are frequently used/requested. > > There needs to be something about how you intend to handle these > newer versions. The canonical choices are: > > 1) overwrite the old version with the new, thus only having one > installed at any given time, or
This is (was) what we are (were) planning for this integration. > 2) have some directory structure/pkg architecture to support the > unambiguous installation and use of multiple versions on a > single system simultaneously If you like, we can expand the scope of this case to include multiple Junit versions. Blastwave uses the jar file name to communicate the version information, which is one approach and the way we have it organized in this case: http://www.blastwave.org/filesearch.php/junit /opt/csw/share/java/junit.jar /opt/csw/share/java/junit-4.jar /opt/csw/share/java/junit-4.2.jar dbunit and abbot both depend on junit 3.8.2. So, we could include it to establish how we handle multiple versions. dbunit and abbot are viable open source packages for us to port. We could update the spec interfaces to look like this, with the man page and documentation focused on the most recent version. /usr/share/lib/java/junit.jar (link to latest version) /usr/share/lib/java/junit-4.5.jar /usr/share/lib/java/junit-4.5-src.jar /usr/share/lib/java/junit-3.8.2.jar /usr/share/lib/java/junit-3.8.2-src.jar /usr/share/man/man3/junit.3 /usr/share/doc/junit The goal here is to avoid having every tool that needs junit have to include it separately. It's much more efficient to just change the CLASSPATH. > If 1, why are you doing something that isn't well aligned with > the known use-case for the component, and if 2, how will you > actually do it? Is Maven the "known use-case"? Junit is more general than that. It's designed to test any Java code. It's clear, people are looking for it "as-is", and it's important to have a standalone IPS package for it. BTW. Regarding: "Maven build system expects to find junit in a specific place". That seems flawed to me. Maybe we should push a Maven change upstream. Cheers, Jim -- Jim Walker, http://blogs.sun.com/jwalker Sun Microsystems, Software, Solaris QE x77744, 500 Eldorado Blvd, Broomfield CO 80021
