ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Conor MacNeill <>
Subject Re: [Ant2] Tasks as siblings of <target>
Date Mon, 05 Nov 2001 10:04:24 GMT
Tim Dawson wrote:

> Stefan writes:
>>>I would prefer (1) if we made it a normal target.
>>Which would be the old unmodified "no tasks outside of targets" which
>>received a -1 by Conor ...
> Well, he has to -1 it again now, doesn't he? 



I think there are a number of reasonable reasons for having global 
properties. First of all just about all current Ant build files use this 
pattern. They could have used "init" targets but most people chose to 
use global properties. This is true even when there is some other init 
tasks that get done such as making directories. Apart from being an 
established usage pattern, I think it is also a usability issue. When I 
look at a buildfile for the first time I can see pretty much straight 
away what are the "control points" for the build - "OK, I can turn 
deprecations on here, change the build area there, etc". These control 
points are important because they will be the things I override from the 
command line or from <ant> calls when I use this buildfile.

Moving this declaration into a target will make that less obvious. That 
isn't to say I am against an <init> element or even an init attribute on 
the project. I'm not that keen on the latter as it causes surprises when 
it has depends attribute. Even Bevan's definition

 > The "contract" could be simply that the initialise target always gets 
executed first, reguardless of what other targets are invoked.

fails in the face of a depends attribute. That can be overcome, of 
course - just depends how mucgh support you want to do on ant-user. So I 
see the issue of top level tasks and an init solution in whatever form 
as not being necessarily mutually exclusive.

> I don't think a "-1000" counts
> for the next thousand times the vote is brought up. :-)

I don't think I -1'd it originally but vetos cannot, in general, be 

> Someone had a problem with this because what if "getReady" had
> depends="foo".  But I didn't really think that would be much of a problem.
> Another issue that was raised that I don't quite understand is that
> supposedly preprocess/validation requires top-level tasks. I mean, wouldn't
> it be possible to just execute the init target, and then validate all the
> other targets? this is effectively what happens if you have top level tasks.

In Ant2, we want to strongly separate parsing from execution. In my 
view, parsing will contruct an object model of the build file which will 
be handed to the execution part of Ant. There will no effective 
communication between these two phases apart from the build model 
itself. Some things (not necessarily many) need to be processed and 
validated in the parsing stage. This is why "target" and some other 
keywords ("projectref", "include", whatever) will be coded into the 
parser because it allows the parser to contruct the build object model. 
Everything that is not specifically recognized will probably be 
collected into a model component that supports arbitrarily nested XML 
elements. This will of course be used for tasks/types but may also be 
used for other constructions which need to be processed in the execution 
phase. So, there should be sufficient extensibility in the model for 
other elements without making the parsing phase some sort of stripped 
down DOM builder or taking on the "everything is a task" view.

option (1) -1 but not necessarily against <init>, init=""
option (2) +1

option (3) +0 - can be done in execution stage only and not necessary if (2) goes.

(Happy to discuss further).

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message