ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Bucanek <>
Subject Re: init targets
Date Sun, 17 Dec 2000 23:57:35 GMT
At 7:04 PM +1100 12/17/00, Conor MacNeill wrote:
>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

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} cleanup

This 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

View raw message