So even though there is all this code in all the build scripts specifying the junit.jar in ./thirdparty/junit/junit/lib, the junit.jar actually getting used is in ./tools/lib. There are classes overlapping in ./thirdparty/apache/log4j/lib/log4j.jar and ./tools/lib/log4j-core.jar. In the jmx sub-project build.xml, sax2.jar and sax2-ext.jar, located in ./thirdparty/xml/sax/lib are used which have overlapping classes with crimson.jar in ./tools/lib. Further, there additional copies of crimson.jar, jaxp.jar, and xalan.jar in both ./tools/lib and ./thirdparty/sun/jaxp with different dates and sizes. These files are referenced in the top level build.xml.
There is a duplicate bsf.jar in the ./thirdparty/ibm/bsf/lib, but it doesn't seem to be used anywhere.
If this really is a problem, several of us could be banging our head against the wall trying to solve a bug in an old .jar. Perhaps we should remove any .jar that appears in the thirdparty directory from ./tools/lib, and only keep Ant required files there. I would like the xdoclet .jars moved into the thirdparty. That way, as we develop new xdoclet templates for generating deployment descriptors and code generators, we can evolve them, before submitting them to be included in the XDoclet codebase. The relevant shell script was in ./tools/bin/ant:
# add in the dependency .jar files
DIRLIBS=${ANT_HOME}/lib/*.jar
for i in ${DIRLIBS}
do
# if the directory is empty, then it will return the input string
# this is stupid, so case for it
if [ "$i" != "${DIRLIBS}" ] ; then
if [ -z "$LOCALCLASSPATH" ] ; then
LOCALCLASSPATH=$i
else
LOCALCLASSPATH="$i":$LOCALCLASSPATH
fi
fi
done
Frederick N. Brier
Sr. Software Engineer
Multideck Corporation
