Bug 20344 - [PATCH]Allows record task to use XmlRecorder
Summary: [PATCH]Allows record task to use XmlRecorder
Alias: None
Product: Ant
Classification: Unclassified
Component: Core tasks (show other bugs)
Version: 1.7.0
Hardware: All other
: P3 enhancement with 1 vote (vote)
Target Milestone: ---
Assignee: Ant Notifications List
Keywords: PatchAvailable
Depends on:
Reported: 2003-05-29 23:21 UTC by Kris Bravo
Modified: 2009-07-30 08:05 UTC (History)
0 users

Patch file and new files in tar.gz (6.28 KB, application/octet-stream)
2003-05-29 23:25 UTC, Kris Bravo
Changed source files (4.81 KB, application/x-tar)
2005-03-04 15:46 UTC, Kris Bravo

Note You need to log in before you can comment on or make changes to this bug.
Description Kris Bravo 2003-05-29 23:21:54 UTC
Currently, Ant supports logging as XML by specifying a logger on the 
command line:

ant -logger org.apache.tools.ant.XmlLogger -verbose -logfile build_log.xml

There are a few limits to this. The log file and listener must be specified 
on the command line instead of in property fields or a file. Also, the 
log file is produced at the end of the build, so transforms and other 
followup operations have to be performed from another build script.

This patch modifies the record task to allow a Recorder to be specified.
XmlRecorder, a subclass of XmlLogger, is included in this patch and can be 
used to produce the XML log output. This may then be transformed from within 
the build.xml.

The ant Record core task's documentation is updated to reflect the change.
Listener is removed from the wishlist at the bottom of Record's html file. 
After looking into the code, I found it more appropriate to refer to the 
attribute as a recorder (sticking to the codebase' naming convention).

Here, a java compile task is recorded, and the resulting log.xml file 
is used to produce html output.

    <record name="log/log.xml" recorder="org.apache.tools.ant.XmlRecorder"
    <javac ...
    <record name="log.xml" action="stop"/>
    <style basedir="log/" includes="log.xml" destdir="doc/" 

The tar.gz attachment includes the patch, new files. See recorder.make for
the list of changed and new files.

  The code has been tested with the XmlRecorder, no recorder, and for regression 
using the command line method. 

  The XmlRecorder will not add entries when the recorder is restarted. I figured 
it would be best to get this in first and learn the process 
(my first public patch ever). If restarting is needed I'll improve the code later.
Comment 1 Kris Bravo 2003-05-29 23:25:27 UTC
Created attachment 6562 [details]
Patch file and new files in tar.gz
Comment 2 Kris Bravo 2005-03-04 15:46:09 UTC
Created attachment 14401 [details]
Changed source files

A few people have shown some interest in my change, so I've updated it for the
ANT_162 tag.

Since I appear to have botched the first patch I attached, I've simply attached
the changes files this time.

Note: This change implements the following from the wish list on the
CoreTasks/Recorder.html page:

listener	A classname of a build listener to use from this point on
instead of the default listener.
Comment 3 Kris Bravo 2006-09-19 20:18:21 UTC
This patch request has now past the three year mark. I'm not sure what the
outcome has been of other patches but to anyone looking for this type of
functionality I'd recommend moving from ant to Maven 2.


Also, continuum (same site) handles automated builds well.

No more updates on this patch will be done.
Comment 4 Matt Benson 2006-09-19 20:36:38 UTC
I'm sorry your experience has been negative.  It can be hard to get patches
noticed if you don't nag the right people and find a committer who is interested
enough to push them through.  I am reopening this because I didn't see any
reason other than your disgust that this patch couldn't go in in one form or
another... unless you are actually rescinding the IP grant you made when you
closed the issue report.

Comment 5 Peter Reilly 2006-09-19 20:44:41 UTC
especially with ~400 outstanding enchancement requests
Comment 6 Kris Bravo 2006-09-20 14:48:13 UTC
I'm not rescinding the offer, but did want to create a pointer if someone was
looking for this type of behavior from a build tool. I assumed that eventually
all patches get either merged, rejected or overcome by events. This patch is
getting closer to the latter given the timeframe. The comment on the ticket is
to keep folks from hitting a dead end.

As for nagging someone to roll it in, I suppose I should have. In Maven's case,
I became a committer on the plugins project to avoid this type of situation.