There are basically two ways to get JXCL - and most other open source software. The first is CVS, which gives you access to last night's version of the code. The second is to download the latest release. This is more likely to work, but is less up to date; current plans are to put out incremental JXCL releases at roughly 2 week intervals.
JXCL is being developed on systems running Linux and FreeBSD. If you are working under a Microsoft operating system, you may need to use some initiative to get the advice that follows to work. We will try to improve on this situation; please be patient.
At the time of writing (August 2004), JXCL has been split into its two major components (JXCL and UCovered), but all changes have not yet been reflected in CVS. The 0.7 releases incorporate fixes for several bugs and are a significant improvement on 0.7a4. Therefore, while CVS access to 0.7a4 is available, it makes more sense to download the two 0.7 tarballs.
JXCL is hosted on SourceForge. On Unix systems, you can get a copy of the most recent version of JXCL by typing:
cvs -d:pserver:email@example.com:/cvsroot/jxcl checkout jxcl
This will deliver the very latest version to your desktop, creating a jxcl subdirectory in the current directory.
If you are using another operating system, or have trouble with the instructions above, have a look at Sourceforge's CVS documentation; this is lucid and reasonably easy to follow.
The alternative is downloading a tarball. This is very simple indeed. You should see a Download button at the top of this Web page; if you click on it, it will take you to JXCL's Sourceforge download page. The most recent tarballs will be listed towards the top.
There are two current tarballs, one for the base JXCL
code and one for the UCovered Java coverage utility.
The current JXCL tarball will have a name like
jxcl-0.7.tar.gz and the UCovered tarball
a name like
0.7 represents the current release.
You should download both.
Javadocs are included with both tarballs.
Just click on the most recent tarballs, and your browser will get them for you.
Once you have a tarball, put it in the directory where you want your JXCL subdirectory and type something like
tar -vzxf jxcl*gz
and it will be extracted for you. (These instructions are of course suitable for Linux/Unix hosts; if you are using Windows, you need to adjust appropriately.)
When you de-tar the JXCL tarball, it will create a
jxcl directory with subdirectories for each
jxcl jxcl lib ant ant-1.5.4.jar optional-1.5.4.jar LICENSE junit junit-3.8.1.jar ... ucovered
lib subdirectory is where the jars live.
The jars are organized by
groupId, which is more
or less the vendor name. These are all open source products.
The subdirectory also contains the license for the group.
You can now actually use UCovered. To run a demonstration, just type:
cd jxcl/ucovered/example/3x6 ./build.sh test
This will compile the tests and source code under
Java classes under
jxcl/ucovered/example/3x6/target, and then
run the unit tests to produce a coverage report.
The tests can be run with or without Ant. The non-Ant run is done using
Alternatively you can do a full Ant build and run the tests by typing
This command file uses
classpath.sh to set
up the classpath for Java.
Each of JXCL's component directories is organized the same
way. There are three source code directory trees and then a
similar set of three class trees in the
subdirectory. For example, the
has this directory structure:
jxcl jxcl classpath.sh build.sh build.xml src java org jxcl test org jxcl test-data target classes test-classes test-data-classes
Ant builds are done by typing
build.sh first sets up the Java classpath by
classpath.sh and then invokes Ant
build.xml as the build file. Since the
test, it will first compile the
three groups of source code. Java files under
src/java/org/jxcl are compiled into classes
target/org/jxcl, and similarly for
the unit tests under
test-data Java source files are a set
of test cases used in verifying JXCL and UCovered
The test build should execute with no or very few errors. If you do see serious errors, it is likely that there are problems with the installation. The most likely problems are classpath errors and missing jar files.