Re: PROPOSE: Property Trace Facility For Ant?
Craeg Strong wrote:
Dominique Devienne wrote:
Changing an interface is a no-no of course.
So far I think I like #1 best, i.e. adding a few overrides to the log
methods in ProjectComponent to support an additional category. I'm not
sure we'd need hierarchical categories a la Log4J or
java.util.logging. Makes it more complex, and we don't want to slow
down Ant's logging. --DD
Yes, I see that this kind of approach would be simpler. How about the
following:
A) enhance the Property task to log a message when it sets a property,
just like XmlProperty does, e.g.
(2 lines of code)
[xmlproperty] foo:MUMBLE
Setting project property: foo - MUMBLE
[property] foo:BARF
Override ignored for property foo
B) enhance PropertyHelper to log a message when it resolves a property
in replaceProperties, e.g.
(1 line of code)
Retrieving project property foo:MUMBLE
[echo] value is MUMBLE
The idea is that if you need to trace a particular property, say foo
you can grep the -debug output. Not bad...
There are several options for when to print the log messages:
1) make it happen in debug, which makes debug even more verbose
2) add logging categories, so property traces only show up when you ask
for them
3) add a sixth logging category like MSG_TRACE which will include all
debug info + property trace (and maybe more)
(buildfile follows)
xmlproperty file=somefile.xml/ !-- sets foo to MUMBLE --
property name=foo value=BARF/
target name=test
echovalue is ${foo}/echo
/target
Actually, I quite like the listener approach. We just need an extended
listener; there is no reason the -listener command can't handle both types.
The nice thing about a listener is that it lets an IDE do fancy things
like list all properties.
if we are going to do this, we should also extend the listener with info
about every reference created.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: PROPOSE: Property Trace Facility For Ant?
Steve Loughran wrote: Actually, I quite like the listener approach. We just need an extended listener; there is no reason the -listener command can't handle both types. The nice thing about a listener is that it lets an IDE do fancy things like list all properties. if we are going to do this, we should also extend the listener with info about every reference created. Let me see if I am following you. You are imagining a new interface, sth like ReferenceListener that could have several different implementations like BuildListener does today. Project.java would hold a collection of reference listeners along with the existing collection of build listeners. The new interface could have methods like propertySet() propertyGet() referenceAdd() referenceGet()... The -listener command line option could take instances of either Interface. addBuildListeners() in Main.java would have to be extended to figure out which Interface was implemented by the logger with the passed in classname. Hmm. Might it be cleaner to add a new command line option? --Craeg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PROPOSE: Property Trace Facility For Ant?
Have you ever changed the value of a Property, re-run the build, but did not get the result you wanted? Yep! 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 does. (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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PROPOSE: Property Trace Facility For Ant?
Dominique Devienne wrote:
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.
Cool! Continuing this thought experiment, what about enhancing
BuildListener like so:
/**
* Signals that a property has been set.
*
* @param event An event with any relevant extra information,
* for example, the name of the property and whether
* the property was set successfully or was an ignored
override.
*/
void propertySet(PropertyEvent event);
/**
* Signals that a property has been retrieved, for example,
* the text I am using the ${foo} property in an echo task
* could trigger this event.
*
* @param event An event with any relevant extra information,
* for example the name of the property.
*/
void propertyGet(PropertyEvent event);
You could have PropertyHelper fire the propertyGet event in
replaceProperties(), for example.
The issue with these events is the same one you normally have with
exceptions.
That is, at the time an exception is thrown deep in the guts of a
program you typically don't have enough context.
Here in replaceProperties() we don't have a reference to the calling
Task, only the Project.
The typical solution for exceptions is to cascade them up the chain,
either directly or within an enclosing Exception.
A similar approach for events might be to simply accumulate the
propertyGet events within the scope of the PropertyHelper and then
print them out later in the taskFinished() event message.
Alternatively, we don't worry about the loss of context,
relying on the surrounding taskStarted/taskFinished events to provide
the context-- as long as there are not multiple threads going on.
What do you think?
--Craeg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: PROPOSE: Property Trace Facility For Ant?
On 11/9/05, Craeg Strong [EMAIL PROTECTED] wrote: Cool! Continuing this thought experiment, what about enhancing BuildListener like so: Changing an interface is a no-no of course. The issue with these events is the same one you normally have with exceptions. I can't comment on your approach, since I don't think I understand it. Alternatively, we don't worry about the loss of context, relying on the surrounding taskStarted/taskFinished events to provide the context-- as long as there are not multiple threads going on. This is precisely what I proposed to do in my design #2 based on a listener. So far I think I like #1 best, i.e. adding a few overrides to the log methods in ProjectComponent to support an additional category. I'm not sure we'd need hierarchical categories a la Log4J or java.util.logging. Makes it more complex, and we don't want to slow down Ant's logging. --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PROPOSE: Property Trace Facility For Ant?
Dominique Devienne wrote:
Changing an interface is a no-no of course.
So far I think I like #1 best, i.e. adding a few overrides to the log
methods in ProjectComponent to support an additional category. I'm not
sure we'd need hierarchical categories a la Log4J or
java.util.logging. Makes it more complex, and we don't want to slow
down Ant's logging. --DD
Yes, I see that this kind of approach would be simpler. How about the
following:
A) enhance the Property task to log a message when it sets a property,
just like XmlProperty does, e.g.
(2 lines of code)
[xmlproperty] foo:MUMBLE
Setting project property: foo - MUMBLE
[property] foo:BARF
Override ignored for property foo
B) enhance PropertyHelper to log a message when it resolves a property
in replaceProperties, e.g.
(1 line of code)
Retrieving project property foo:MUMBLE
[echo] value is MUMBLE
The idea is that if you need to trace a particular property, say foo
you can grep the -debug output. Not bad...
There are several options for when to print the log messages:
1) make it happen in debug, which makes debug even more verbose
2) add logging categories, so property traces only show up when you ask
for them
3) add a sixth logging category like MSG_TRACE which will include all
debug info + property trace (and maybe more)
(buildfile follows)
xmlproperty file=somefile.xml/ !-- sets foo to MUMBLE --
property name=foo value=BARF/
target name=test
echovalue is ${foo}/echo
/target
--Craeg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
PROPOSE: Property Trace Facility For Ant?
Greetings! 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 answer.to.great.question 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 maintain. 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 answer.to.great.question propTrace[SET] File: build.xml, [property] Setting project property answer.to.great.question - 42 propTrace[SET] File: build.properties [property] Override ignored for property answer.to.great.question:43 propTrace[SET] File: properties.xml [xmlproperty] Override ignored for property answer.to.great.question:44 propTrace[GET] Target: compile [javac] Accessing project property answer.to.great.question:42 propTrace[GET] Target: dist [zipfileset] Accessing project property answer.to.great.question:42 propTrace[GET] Target: dist [ftp] Accessing project property answer.to.great.question:42 Implementation I could submit an initial implementation modeled after BuildListener/BuildLogger/ BuildEvent/DefaultLogger (PropertyListener/PropertyLogger/PropertyEvent/PropertyTracer) that logs output to stdout. I am certainly open to an alternative implementation. Risks 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
