GitHub user gagern opened a pull request:
https://github.com/apache/ant/pull/3
junitreport: Expose classpath and factory of internal XSLTProcess task.
Trying to revive [bug
47002](https://issues.apache.org/bugzilla/show_bug.cgi?id=47002) by filing a
pull request for it.
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.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gagern/ant 47002-junitreport-classpath
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ant/pull/3.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #3
----
commit 95ea95ce56b27a68660a04bcfa8abde2add0dcf3
Author: Martin von Gagern <martin.vgag...@gmx.net>
Date: 2014-11-26T12:50:50Z
junitreport: Expose classpath and factory of internal XSLTProcess task.
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.
----
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
