ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craeg Strong <>
Subject PROPOSE: Property Trace Facility For Ant?
Date Wed, 09 Nov 2005 07:02:26 GMT

Have you ever changed the value of a Property, re-run the build, but did 
not get the result you wanted? 
Did you wonder if the property setting got ignored (ignored override), 
or if something else was wrong?

Have you ever wondered where in the world the 
property might be used? 
What would happen if you changed the value from 42 to something else?

I find myself in these situations when working on a large (several 100K 
or 1M+ SLOC) software project with many build files
and property files that I did not write myself but am now obliged to 

What I normally do is use the "-debug" option, then insert lots of 
<echo> tasks,
and finally hack the buildfile to narrow down the scope of the problem 
until I find what I am looking for. 
It would be nice if Ant offered some debugging support for these issues 
that did NOT require any changes whatsoever to the build files or 
property files.

  Proposed Solution

Add a property trace facility similar to the build logger facility.
It could include a default implementation that simply logs whenever a 
particular named property is set or get. 
The facility could offer the following beyond what "-debug" provides:

- location where a particular property setting came from
- location where a particular property is used
- the location could start off coarse grained (file name, project name), 
then get more sophisticated in later iterations (line number, target 
name, etc.)

IMO, this facility would add an important new management capability to Ant.

  Example Usage

ant -propTrace

propTrace[SET] File: build.xml, [property] Setting project property -> 42
propTrace[SET] File: [property] Override ignored for 
propTrace[SET] File: properties.xml [xmlproperty] Override ignored for 

propTrace[GET] Target: compile [javac] Accessing project property
propTrace[GET] Target: dist [zipfileset] Accessing project property
propTrace[GET] Target: dist [ftp] Accessing project property


I could submit an initial implementation modeled after 
that logs output to stdout.  I am certainly open to an alternative 


The Ant API for setProperty, getProperty, and variants would need to be 
enhanced to accept
a reference to some sort of Location object which could contain things 
like fileName, projectName,
targetName, etc.  Unfortunately these APIs are quite widely used, so we 
would have
to add the new APIs and keep the old ones, which increases the size and 
complexity of Ant.
Changing all of the taskdefs to use the new "annotated" getProperty API 
would require small changes to many files. 

This is the crux of the issue-- I am discouraged by how many files would 
have to be changed to implement this capability. 
Does that make it too "expensive" ?

  Comments, please!

--Craeg Strong

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

View raw message