ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Murdoch <>
Subject Re: Top level tasks
Date Mon, 15 Jul 2002 21:35:01 GMT
On Tue, 16 Jul 2002 02:55, Stefan Bodewig wrote:
> The things that are still broken:
> (1) You can throw Ant into an infinite loop with <ant> or <antcall> at
> the top level calling the same build file - this will not be caught
> ATM as Main sets the ant.file property after parsing the build file
> but the task gets executed while parsing it.
> (2) -projecthelp will run the top level tasks.
> Both are symptoms of the same misconception - ProjectHelper shouldn't
> execute any tasks IMHO.
> Now the question to those people that have already done what I'm
> trying to do in Mutant and Myrmidon: How have you done that?  Why have
> you done it that way?
> Right now I'd say that ProjectHelper should stuff all top level tasks
> and data types into an anonymous target and hand that target of to
> Project.  If project is asked to execute, then run this implicit
> target before calling anything else.

We've done pretty much the same thing in myrmidon:

- Split project parsing from project execution.  The parse step builds up the 
project model but does not (cannot) execute anything.  The project model is 
immutable, and doesn't hold any execution state, so that it can be reused a 
bunch of times (by a gui, or in <antcall> for example).  Targets are  
represented using a dom-like object, rather than the task objects themselves.  
The tasks are created at execution time only.

- All the top level tasks and datatypes get added to an initialiser target, 
which all other targets implicitly depend on.

Works quite well.  Having the implicit init target gives the ProjectBuilder 
(ie the thing that parses the build file, kinda like ProjectHelper) lots of 
scope for doing interesting things.  Having an implicit cleanup target might 
also be useful.


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

View raw message