[off-topic] position available for ant expert in NYC, USA
Hello: Some of you may remember me as a sometime ant contributor. Well, the project I am working on has need of another Ant expert. If interested, please drop me a line at cstrong at arielpartners dot com thanks, and sorry for the interruption. --Craeg - 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?
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?
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]
Re: Java Development with Ant
Although it will only interest a small number of developers, i would happily contribute a ecmascript/javascript with Ant including JSdoc (similar with javadoc) and JSLint (instead of checkstyle) integration, unit test etc. Manos Yes, Please! I am involved with a large project that is heavily using AJAX technology. The technology is cool, interactive, slick. and so far totally undocumented and untested. I believe your information could really help some of the folks out there (like us) who are struggling with this stuff. my 2c, --Craeg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ant tutorial
This tutorial is incredibly valuable, IMO. I would love to see this checked into CVS and given a permanent home on the ant website, kind of like ant in anger... 2c, --Craeg The first place was a very long time ago and there was a lot of history for why Ant is the way it is. You might be interested in a little tutorial I wrote to try and explain this history: http://codefeed.com/tutorial/ant_config.html Slick. I like it.
