ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin von Gagern <>
Subject [PATCH] [Bug 47002] junitreport: expose classpath of internal XSLTProcess task
Date Thu, 09 Apr 2009 10:24:19 GMT

This is the mailing list inbcarnation of bug 47002.

junitreport does create an internal xslt task to format its report. It
doesn't expose most of the configuration options of that task, though.
In particular, it does not allow the classpath to be specified.

I've been writing a build.xml relying only on ant core, and fetching
optional tasks along with their dependency libs through ivy. I
<taskdef>ed junitreport to its implementing class with a suitable
classpath, but still got a ClassNotFoundException because XSLTProcess
couldn't find its TraXLiaison.

As XSLTProcess itself is core, it was loaded using the main ant
classloader, not the one used to load the optional junit classes like
XMLResultAggregator. That class loader didn't know about my additional
libs, so adding ant-trax to the classpath used when redefining the
jnitreport task didn't help at all.

While some cleaner solution to load tasks on the fly would be desirable,
and I filed
about this, the quick solition would be to provide some nested classpath
element, maybe as a child of the report element.

This patch creates the nested XSLTProcess at creation of the
AggregateTransformer, not upon execution of the transformation. This way
it is much easier to simply wrap parts of the interface I'd like to
expose, like the new <classpath> and <factory> nested elements, but also
the existing <param> elements.

I haven't called XSLTProcess.init(), as the previous code didn't do that
either. I don't fully understand the difference between init() and a
constructor, but it might be a good thing to init the task somewhere.

The approach I chose is something like a whitelist delegation: the
XSLTProcess is a private member, and only selected methods of its
interface are wrapped and thus exposed to be configured. As an
alternative, one could do something like a blacklist delegation by
deriving a class from XSLTProcess and forbidding access to certain
settings by ovverriding the corresponding methods and throwing
exceptions therein. In that case, one might even turn the class derived
from XSLTProcess into a nested <xslt> element, which would be probably
much clearer, as it would be configured in the same way that a top-level
<xslt> task is. I didn't choose this approach in my patch for now, but
if you prefer it, I can implement that as well.

Please review,
 Martin von Gagern

View raw message