OK, so your proposal addresses that somewhat by naming the init target as an attribute of project. Nevertheless, I still don't
really like it. If that target has a depends clause, what does that mean. Should those targets be evaluated before the init target.
That seems to violate the contract of the init target. If you wanted to go this route, then I feel we would need to have a separate
<init> element which functions somewhat like a target but without the depends, if, unless, etc clauses. Then the special nature of
the target is part of the build file structure and sensible behaviour, such as no depends, is dictated by the structure and not
convention.
I would be included to leave the 'init' target(s) just as regular targets simply because I would want those capabilities. Especially, conditional dependant targets that might be required to do platform/purpose specific initialization.
As for trying to create a structure that would eliminate the possibility of an init (or success, or failure) target that had dependencies doesn't seem practical in the presence of the the Antcall task. ;)
I guess it doesn't bother me because it doesn't create any logical inconsistencies, or invalid states, within Ant. It's just a target, like any other target, just one you can't *forget* to run first (or last, or whatever). I was thinking it was more of a crutch or helper than a different kind, or special type, of target.
It is similar for an onfailure target. What if it has depends? What if it fails?
Well, off hand I would say that if all of the _user requested_ targets succeed, or if any fail, then the appropriate post-processing target would be executed, obviously ignoring the success or failure of any of those targets. What would have to be defined clearly would be the timing of calls made to the BuildListener.
Also, adding feartures and then allowing them to be disabled is OK for a small number of features. After that it becomes combersome
and can be seen as an attempt to please everyone. Optionality is not always a good thing.
Agreed. I was just trying to satisfy Diane Holt's complaint that there are times when you wouldn't want any pre or post processing targets to run.
I am not trying to discourage you from pursuing this, but I think you really need to think it through fully both in terms of build
file structure (new elements) and the necessary processing.
I'm become thoroughly ambivalent about this feature. This occurred to me when I realized that all of the functionality of the pre-processing target, and some of the functionality of the post-processing target(s) could be accomplished simply by writing them into the script that calls Ant:
bla bla bla ...Ant init ${usertargets} cleanupThis would accomplish about 50% of the functionality with no changes to Ant whatsoever. And this is, more or less, what I've just done with the GUI shell I'm writing.
The issues is doesn't address are (1) it defeats the default target concept (unless you wrote that into your shell script too), and (2) it couldn't provide for success or failure target execution since any failure would stop the build.
So, I'm just floating the idea. If people find themselves hacking Main or their BAT files to accomplish this, then it seems like a useful, convenient, feature. I don't feel that it's something that warrants altering the syntax of the build scripts, however.
__________________________________ James Bucanek <mailto:[EMAIL PROTECTED]>
