https://bz.apache.org/bugzilla/show_bug.cgi?id=59905

https://bz.apache.org/bugzilla/show_bug.cgi?id=59906

https://bz.apache.org/bugzilla/show_bug.cgi?id=59860

https://bz.apache.org/bugzilla/show_bug.cgi?id=59863

https://bz.apache.org/bugzilla/show_bug.cgi?id=59855

https://bz.apache.org/bugzilla/show_bug.cgi?id=47552

Patch-by: Matthew Yanos

https://bz.apache.org/bugzilla/show_bug.cgi?id=59402

-----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iEYEABECAAYFAlcIo6wACgkQohFa4V9ri3IRRwCfcxfYLPYUc3QagPByDInVc8eZ
 GlkAnRfdSsB3qDFvhZYJXwZzgh1b6qMU
 =GdAj
 -----END PGP SIGNATURE-----

Merge tag 'ANT_197_RC1' into 1.9.x

Tagging RC1 for version 1.9.7 of Ant

Added since tags.

https://bz.apache.org/bugzilla/show_bug.cgi?id=58840

https://bz.apache.org/bugzilla/show_bug.cgi?id=58908

http://stackoverflow.com/questions/34588194/attribute-extension-in-xslt-task-doesnt-work

BZ 58555: https://bz.apache.org/bugzilla/show_bug.cgi?id=58555

https://bz.apache.org/bugzilla/show_bug.cgi?id=58054

- clarify what "availibility" means
- fix </td> on @postProcessGeneratedJavadocs

https://bz.apache.org/bugzilla/show_bug.cgi?id=43271

Apparently the remote umask still comes into play and the result won't
be exactly what we intended it to be.

Based on patch by Holly Cummins

This is a workaround for Bugzilla Issue 57822
https://bz.apache.org/bugzilla/show_bug.cgi?id=57822

Submitted by Roman Savko
PR: 57789

Bugzilla Issue 26814

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.