I think pre-1.2, "init" was a special target that executed at start-up. If the documentation still suggests that's the case, then the doc should get updated (if you're so inclined, you can do that and submit a patch-file :)
No, the docs aren't wrong, just a little vague. What caught me out was the statement in the TStamp task that stated:
The best place for this task is in your initialization target.
It was only later, re-reading the general discussion of targets, did I discover that 'the' initialization target was merely a convention, not a special target.
I suppose you could consider adding another <project> attribute, similar to "default" (maybe "boot", or how about "onload" :) that would take the name of a target to always execute, even when other targets have been specified on the command-line (which "default" doesn't do).
That would be a good solution. There would seem to be two ways of handling this:
(1) Implicitly add the 'onload' target(s) to the dependencies of every other target in the system. I haven't looked at how Ant handles circular target dependencies, but if it's self limiting, then this would be a very simple solution. If not, then you'd have to trace out the graph of all the targets that would be triggered by the onload target(s), then fix the dependencies in the targets not in the first set. A little more work, but cleaner.
(2) Modify the code that starts the build to simply build the 'onload' target first, then build the targets selected by the user. In effect, it just prepends the onload target(s) to the list of targets you're going to build.
Now that I think about it, I definitely like (2) best. But why stop with just 'onload'? Why not define both 'onstart' and 'onfinish' targets? Possibly even augmenting 'onfinish' with 'onsuccess' and 'onfailure' targets?
<project name="workhorse" default="main" start="init" finish="cleanup" success="incrementsaleries" failure="firesomeone"/>
Executes: <onstart> user selected targets, ... <onsuccess> or <onfailure> <onfinish>
Since I've written my own wrapper for Ant, I'll go ahead and implement (2). I'd still be curious of any feedback on this idea. Furthermore, where's the scoop on contributing to the Ant project? And, do you guys and gals need anymore help?
James
__________________________________ James Bucanek <mailto:[EMAIL PROTECTED]>
