The xslt task no longer heeds the classpath property. The reason is that in XSLTProcess.java, the resolveProcessor method does not (in the default case) call the loadClass method and therefore the thread context class loader is not set. This is a regression from 1.8.0.
As a workaround, you can explicitly specify processor="org.apache.tools.ant.taskdefs.optional.TraXLiaison" as an attribute of the xslt task.
fixed with svn revision 943143
The fix looks wrong to me. TraXLiaison is part of primary Ant sources, so we should not be loading *it* using some special class loader - unnecessary and risks weird CCEs. The use of getContextClassLoader in TraXLiaison.getFactory is also strange, because it relies on some undocumented side effects from the task. It seems XSLTProcess sets and restores the thread's CCL - but it only sets it in loadClass. 943143 works only because loadClass is called at all - it could throw away the result! Also, using Class.forName(String) from TraXLiaison.getFactory is probably unnecessary and wrong. Perhaps the proper fix is as follows: 1. Back out 943143; as part of assuming JDK 1.4+ I intentionally loaded TraXLiaison directly, since it does not depend on anything outside the JRE. 2. Simplify TraXLiaison.getFactory to not call Class.forName(String). It can continue to use TransformerFactory.newInstance for an unspecified factory; or Class.forName with CCL on a specified factory. (Note that if you are bothering to specify a classpath for the processor, you should very likely be specifying the factory too - else how do you know for sure what you are getting? You could be getting some unrelated factory that happened to be elsewhere in the classpath.) 3. Make XSLTProcess.execute always create loader and call setThreadContextLoader in case classpath != null; do not do this logic in loadClass.
I agree with all of your points.
svn revision 982729 is along the lines of point 1 and 3 of comment #3 I extracted the loader creation into a method that is invoked from execute as well as loadClass since loadClass may be invoked via the protected getLiaison method and there wouldn't be any guarantee that execute has been called at all. I've skipped point 2 since I don't think falling back to Class.forName(string) likely doesn't do any harm (we shouldn't be getting there anyway).
I think it is fixed again and assume Jesse can live with the current trunk code.
Looked OK last I checked.
*** Bug 50289 has been marked as a duplicate of this bug. ***