Okay, committed revision #14076 on the trunk that updates the following jars in the lib directory to the noted versions:

• commons-collections.jar 3.2
• commons-lang.jar 2.3 (added this, and deleted the former variant called "commons-lang-2.1.jar")
• commons-logging.jar 1.1 (mistakenly noted as commons-logging-api.jar in the original issue desc.)
• xercesImpl.jar 2.6.2 2.7.1
• xml-apis.jar 1.0-b2 2.7.1

Also updated the versions-licenses.html file in the lib directory to reflect the updated versions and file names.

Messed up my SVN commit log message, so I reverted and recommitted with correct message. Now at revision #14078.

Ken, Ted, Deryk,

This is fantastic! Thanks so much for doing this!

Neil

Ken,

There is a file named commons-logging-api.jar that:

1) Is present in the "lib" folder
2) Is present in the versions-licenses.html file

But when I look at the contents of the JAR file, it looks like it is identical in nature/function to the commons-logging.jar file, which was recently updated.

Recommend deleting the commons-logging-api.jar file, as I believe it is redundant.

Please seek a second opinion of course!

Thanks,

Neil

Detailed description about commons-logging-api.jar

http://jakarta.apache.org/commons/logging/guide.html#commons-logging-api_jar

The |commons-logging-api.jar| file includes the JCL API and the default |LogFactory| implementation as well as the built-in |Log| implementations SimpleLog and NoOpLog. However it does not include the wrapper |Log| implementations that require additional libraries such as |Log4j|, |Avalon| and |Lumberjack|.

This jar is intended for use by projects that recompile the commons-logging source using alternate java environments, and cannot compile against all of the optional libraries that the Apache release of commons-logging supports. Because of the reduced dependencies of this jarfile, such projects should be able to create an equivalent of this library with fewer difficulties.

This jar is also useful for build environments that automatically track dependencies, and thus have difficulty with the concept that the main commons-logging.jar has "optional" dependencies on various logging implementations that can safely go unsatisfied at runtime.
—

We require the commons-logging-api.jar for our NetBeans IDE integration.

Thanks Ken, good catch, my mistake!

Neil