ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Dawson <>
Subject RE: [Ant2] Tasks as siblings of <target>
Date Tue, 06 Nov 2001 09:14:10 GMT
Conor MacNeill wrote:
> 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. 

I've typically used a separate properties file to handle all my
settings because the buidl files get so damn big, and then I just 
have one <properties file=> tag at the top, but I can see this 
causing a maintainability problem for other usage patterns.

And since my #1 concern is always maintainability, I retract
all my comments that advocated disallowing tasks as siblings 
of target.

There still is the issue, however, of determining what tasks can be
siblings, and making that a heck of a lot clearer to everybody
than it is today.  Perhaps separating these from "built in tasks"
in the docs?

> 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 think if we are careful with the wording in the docs, this concern
be alleviated... if instead of saying "always gets executed first,
regardless of what other targets are invoked", we say "is executed
prior to any named (or default) targets", this shouldn't make it
too confusing for users, who, after all, put the depends in that 
target in the first place.

Having an <init> element is fine too, I just prefer init= because
it matches the default= pattern.

> > 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.

So you're saying that Ant2 will deprecate the ability to compile and
define a new task in the same build file? We do this in some of our
applications and its pretty darn useful.

I think that you can separate the parse & construction of the object 
model into multiple phases.  A target could be initialized with either
a list of tasks, or with an XML DOM tree that would need to be further
parsed into a list of tasks upon first execution.

If the desire is to provide validation of the XML file, why not just 
use namespaces and DTDs or schemas?

(ducks and runs for cover...)


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

View raw message