Bug 46058

Summary: Ant needs a streamable log format
Product: Ant Reporter: Stefan Bodewig <bodewig>
Component: CoreAssignee: Ant Notifications List <notifications>
Status: NEW ---    
Severity: major CC: jmelzer
Priority: P2    
Version: 1.8.2   
Target Milestone: ---   
Hardware: All   
OS: All   

Description Stefan Bodewig 2008-10-21 21:05:00 UTC
This is an enhancement request, but a very important one, thus I've decided to mark it "major" instead of enhancement.

The number of bug reports on OutOfMemoryExceptions caused by XmlLogger is pretty big and the root cause always is that XmlLogger builds up the DOM tree in memory and only writes the log at the end of the build process.

It has been suggested that a different implementation of XmlLogger that writes the XML file incrementally could be done, but I'm not convinced this could work in the presence of <parallel> or even a custom TargetExecutor that runs different targets in parallel.  I don't think we'd be able to write the log in more granular steps than "write once per target of the top level build file", which may be enough to already cause OOM conditions if the target contains <ant> tasks that call big subbuilds.

Instead I think we should create an alternative output format for Ant's log (and probably do something similar for JUnit) that preserves the benefits of the XML log but can be streamed at the same time.

Requirements would be:

* be aware that multiple different threads may be logging at the same time

* be aware that mutliple targets and even multiple projects may be executing in parallel

* machine readable

* preserve hierarchies, i.e. for a single log entry it must be possible to know to which task, target and project it belongs (where project may belong to a task that in turn ...)

* logentries are written as soon as possible

* the logfile is always well formed and doesn't need any closing "tag"

* optionally: human readable - we could provide a tool that transforms a log to XmlLogger's format

This probably means that timing informations become log entires on their own right that act as an addendum to a "finished" event.

I have a few ideas how to omplement this, but would prefer to collect more feedback first.
Comment 1 Stefan Bodewig 2008-10-21 21:11:29 UTC
*** Bug 35476 has been marked as a duplicate of this bug. ***