ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Cook" <jimc...@iname.com>
Subject RE: Ant 2.0 - Frantic: How are properties resolved?
Date Tue, 16 Jan 2001 01:08:12 GMT
> -----Original Message-----
> From: Peter Donald [mailto:donaldp@apache.org]
> Thats what I thought - I am completely and utterly -1 on this aspect.
> Mainly as it becomes so hard to maintain and requires heaps of extra
> programming in 90% of the cases. (It is useful in some instances but....)
> It should be the containers responsibility rather than components. The
> reason is that moves all complexity to us and leaves task writers with a
> cake walk ;)

Please elaborate. As far as putting more complexity on us (Ant design), I
don't see it. In fact, the code that exists now fully supports complex
property substitution. What is the issue?

> >The HierarchialHashtables are a means of storing property values
> in a scoped
> >manner, but they go ahead and store properties in their ${}
> form. When the
> >property is requested by the Task, it is substituted at that time.
>
> Yep - so you have two object trees - the real object tree and the proxy
> object tree ?

When the program starts, all I have is an object tree. As Tasks get executed
and nesting levels ensue, I build a property tree that represents the
runtime structure of the build process. You need two trees because the
static view (the XML file) does not equal the runtime view. The runtime view
can jump all over the place in a manner that is not reflected by the task
hierarchy.

jim


Mime
View raw message