ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: Top level tasks
Date Mon, 15 Jul 2002 19:00:44 GMT wrote:
> Parsing is relatively separated from the rest. The real question is 
> the execution model.
> I see no problem with treating all top level elements as a 
> 'default' target, with all other targets having an implicit 
> dependency on it. That's actually the way it was implemented
> few years ago, before a vote decided to change it ( and 
> forbid top level tasks ).

Hey, I think that having toplevel tasks is not the best solution, 
because it can be confusing, as to when they are executed.
If I have a target and after that some top-level tasks, will they run 
after the target? (kinda joking, I hope you hear the voices of puzzeled 
users ;-)

What I would really like and what many people have asked me for 
Centipede, is the possibility of having targets that are *always* 
executed *before* and *after* the build.

In this way, in an organization, I can have all my ant projects that 
import the basic one with default pre and post targets, that can check 
if the results comply with rules I have determined, or I can predefine 
some ant properties, used by other imported targets, that can thus not 
be overwritten.

So we could have (fun tags ;-)

   <target name="ccc">...</target>
   <target name="ccc">...</target>

Beware, this does *not* add pre and post stuff to targets, which is 
kinda bad like I've already explained, but to the whole build.

> There is no problem with ${} substitution either, as it is
> delayed to the execution stage. Regarding loops - it is possible
> to detect them ( just keep a static execution stack - that can also 
> be used to report errors in a nice way ).
> For things like import we do need some extra API in Project
> and changes in ProjectHelper to expose a separate parsing 
> step and treat the 'top-level' target the same as the other 
> targets ( i.e. delayed evaluation ). That would actually simplify
> the code.


I can do the above in current ProjectHelperImpl with no API changes.

> Costin 
> On Mon, 15 Jul 2002, Dominique Devienne wrote:
>>Yeah, exactly my thoughts too. <import> exists because Ant doesn't have real
>>templating. Would be better to completely separate parsing from execution,
>>as the Ant2 proposal allow, and enable using XLST-like feature within the
>>buildfile to construct the DOM, then hand everything over to the execution
>>engine... --DD

If we put the top-level things in a target, we are effectively 
separating parsing from execution.

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

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

View raw message