Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
From: "James Cook" <jimcook@iname.com>
To: <ant-dev@jakarta.apache.org>
Subject: RE: Ant 2.0 - Frantic: How are properties resolved?
Date: Mon, 15 Jan 2001 22:48:14 -0500
Message-ID: <INEPIJABNNOAONEOKGBFCEMICHAA.jimcook@iname.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <3.0.6.32.20010116124036.00961b30@alphalink.com.au>
Importance: Normal

> -----Original Message-----
> From: Peter Donald [mailto:donaldp@apache.org]
> yep - but now why do you need the runtime tree? ;) Why not just
> use a proxy
> tree. The only advantage I see of the runtime tree is to make everything a
> "task". However you will eventually have to deal with "tasks" like target
> that can not have their proxy data evaluated when they are
> evaluated. Which
> puts you precisely back to the start where each task instance is just a
> convenience 20 line class. At which point the whole advantage of the
> "everything is a class" approach fails I believe. Feel free to convince me
> otherwise thou ;)

The runtime tree allows variables to have scope much like a compiler engine
works when making nested or recursive method calls. Properties (variables)
can be set by a task then a sub task is invoked with the variable equal to
that value. Next the subtask could change the value and invoke another
subtask. As the tasks finish, any variable settings they have made are lost
as they are popped off the stack. (Unless of course, they changed a global
variable which should be allowed.)

Also, scripting support would benefit greatly from being able to dynamically
change the execution path, or perhaps invoking the same task several times,
but with different property values.

jim