[EMAIL PROTECTED] 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 ;-)

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



Reply via email to