ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: Ant support for users who use JUnit5
Date Sun, 18 Feb 2018 20:07:02 GMT
On 2018-02-15, Jaikiran Pai wrote:

> I'm now done with the initial goals that I had in mind for this
> task. I've opened a PR[1] for review. I've included a manual for this
> task and it can be currently found here[2]. I would suggest reading
> the manual first, before reviewing the PR, since the manual will give
> an overall idea of what's being attempted with this task.

> Except for the "fork" mode which is available in our existing junit
> task and which was was in the TODO list, in my previous mail, the rest
> have been implemented in this version. I plan to focus on the "fork"
> mode after this task is made available to users and any feedback
> received.

I'm through with the manual and can see how the lack of fork is a real
limitation. Setting the classloaders up may be a pain with several
classes of Ant leaking into the test's classpath. IMHO forking new VMs
is the only clean way of running tests. And then there are timeouts or
tests that crash the VM, memory settings and all that.

This is not to say the task shouldn't be merged without the fork
feature, I just expect it to get requested pretty soon :-)

> We have 3 pre-defined formatters all of which are capable of receiving
> this streamed sysout/syserr data. Each of these do _not_ hold on to
> this sysout/syserr data in-memory during the execution and instead
> stream it out a temporary file. Once the execution completes and it's
> time to present the result, these formatters stream/read back the
> content from the temp file and write it out in a formatted manner to
> the target report files.

Sounds expensive.

> Furthermore, the XML formatter doesn't use DOM and instead is based on
> Stax for writing out the report. However, even with all this, there's
> one place where I haven't yet been able to avoid reading the whole
> generated sysout/syserr data into memory (thus potentially triggering
> an OOM) - it's the XMLStreamWriter API which for writing out a CDATA
> section (which is what we use for sysout/syserr content) in XML,
> expects the entire String object. I'll have to see if there are ways
> to avoid it, but I think this still is an improvement since this
> loaded content is only held on for a short while in memory, during the
> report writing and will be immediately garbage collected once that's
> done.

CDATA is really just an implementation detail. The stylesheets should
work with properly escaped nested text as well. So as an alternative you
could escape all special characters with entity references and use


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message