ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From gagern <...@git.apache.org>
Subject [GitHub] ant pull request: junitreport: Expose classpath and factory of int...
Date Wed, 26 Nov 2014 12:54:14 GMT
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.vgagern@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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message