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 ;-)
<project> <injection>...</injection> <target name="ccc">...</target> <target name="ccc">...</target> <afterburner>...</afterburner> </project>
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 [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) ---------------------------------------------------------------------
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>