ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jaikiran Pai <>
Subject Re: Ant support for users who use JUnit5
Date Mon, 19 Feb 2018 03:53:16 GMT
On 19/02/18 1:37 AM, Stefan Bodewig wrote:
> 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 :-)
Agreed. I have started the "fork" mode work, but it's probably going to 
take at least acouple of more weekends to get it usable.

>> 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.
Indeed. In 2 ways actually:

     1. The creation of these files.
     2. The fact that we write it out to these files (although in a 
separate thread) and then read it while formatting the result, finally.

It's only applicable for result formatters which want to have the sysout 
and syserr content sent to them, but I expect that most users will want 
this enabled anyway. So yes, it's expensive.

The alternate approach is perhaps to have this content maintained 
in-memory till a fixed size limit (relatively large enough but not too 
much that it will cause OOM) and only create and stream into temporary 
files if that size limit is exceeded. That way the temp file creation 
and writing/reading perhaps can be avoided/controlled in most of the cases.
>> 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
> writeCharacters.
Thank you - I hadn't thought of it and my mind was just fixed on the 
CDATA usage. I have updated that PR to encode the characters and then 
use writeCharacters to write them out.

Thanks for the review Stefan.


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

View raw message