ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominique Devienne <>
Subject Re: PROPOSE: Property Trace Facility For Ant?
Date Wed, 09 Nov 2005 15:05:19 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?

Yep again!

> 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
> maintain.

The only thing that saved me was that I had written most of these
large multi-build-files builds. I also use a custom <echoproperty>
task which works with <propertyset> which helps the debugging.

> [...]
> 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!

So obviously I'm +1 on adding such a facility, but implementing it the
way you propose is indeed disruptive.

Alternate impls (disclaimer: I'm just thinking aloud here...) might be:

1) Add categories to log messages. You could then change the log
statements in property-related tasks (and in Project) to use this new
"property" log category, and add a switch to the launcher to allow
saying -verbose:property or -debug:property and get only these
particular log messages.

2) A custom troubleshooting listener that filters out messages (at the
desired log level) to show only those matching a given regex (the
property name for example), and show only those. This listener could
keep track of which task (and target/build "path") is issuing messages
to display Location information, kind of like the NoBannerBuildLogger

(1) needs changes to the core, when (2) can be implemented outside Ant
right now. The disadvantage of (2) is that you can't get READ or GET
information, only WRITE or SET (or IGNORED) info. This is usually
enough to troubleshoot property issues though.

The issue you raise is what I read once from Howard M. Lewis Ship
about the importance of traceability. I think I read this in something
related to HiveMind. Someone who knows HiveMind may be able to get a
URL for it ;-)

I hope this helps. Thanks for raising such a good point. --DD

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

View raw message