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 writeCharacters. Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
