-----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEEjacMAN968bDS+dx03bzBJwop0IEFAlyOSHcACgkQ3bzBJwop
 0IEyKBAAlnBfthi2P3J+lmxVuXcloDzMp4pGi8r+VhnW79iWSjH8JCnBp1Pd8M9w
 v8iaE/qUjPJeWqbj/0c6us8x6DwluzBeu9uRohHfuyo+9QxnRfx/wG0olKWiIans
 QyJ3tUBYlMcvXnuvfk44lgP33a0uCEWZClhXjC+LGpLA/BZTsEdt1r8FWEhFD1ND
 gJElk7jDXilLbpGx5Kwibf/NfiLSBkO+uGwY59CZNqYqvrCXC77CaVZqt9lLDb6O
 IrMQoRMJCL1wEaYET+I6dKySwYIc+Nrm5DXPVuTp/SPTWcRPMqmqtrnbkNji0GkI
 r2s/by3BTtgxnoUX2uXThaVA8kaEOK+R8NgxTM2Arq1orvv9QiNpugowStdyQkIE
 eOZ70tL64f7TSgSOobDUxM0u0D334vbbklG5rWCE9+VNuoHGrq/hu5un98mbtuTa
 V/N0V6teR3EljLzV9heT5PJrUE/kg17OMfOCRkwaggByThREc5DIHo7TubiRQL+j
 wrFQv8BVkjTqd7bSH6Zx/Txq1oUxc6AHReQwZ1UlOjEgh8YomabZK02s4LS9bDlL
 CYB9uPZPwv1SjvrVCvBhybcouJp9AfsisrL6We5BMAu/5neGSl9XhyXOY9DeZyNf
 1SXbqZx4j3kn/m1MDaLiBQI/h3uUHaIXzG5M0LYtLgqTwwHd2Wk=
 =tmsP
 -----END PGP SIGNATURE-----

Merge tag 'rel/1.9.14' into 1.9.x branch

Tagging version 1.9.14 of Ant

I've decided to break backwards compatibility with the way I've
overridden runS. The "proper" way would have been to call the one-arg
version from the two-arg version so that subclasses overriding runS
would still get their method called. But I figured it to be extremely
unlikely that such subclasses exist.

This closes #84 pull request at github/apache/ant repo

Use valid markup

Many thanks to Gintas (@twogee) for catching this

This closes #81 pull request at github/apache/ant

for each of the test class that are selected by the <testclasses> usage

In 1.10.5 version (the latest released) of Ant, we used to launch
multiple LauncherDiscoveryRequest (a JUnit 5 construct), one each
for a test class, that belonged to the <testclasses> usage. Commit
3f806148c3 changed it to launch one
single LauncherDiscoveryRequest (and including all those test
classes in that request) because it seemed more logical to do so.
However, recent tests/experimentation of the master branch has
shown that it introduces complexities when the "legacy-xml"
listener (the one which supports generating test results in xml
format that junitreport understands) is used. These complexities
include - expecting each test class to have a separate report file,
but isn't limited to that. Solving these issues isn't easy and
probably not worth it, given that the only reason we started using
a single LauncherDiscoveryRequest is because it just seemed logical
and there is no other strong reason to do so. This commit switches
back to the behaviour that's been there in 1.10.5 version, to issue
multiple separate LauncherDiscoveryRequest(s) one each for the
test class that's selected through the use of <testclasses>.