ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Cook" <>
Subject Re: Ant 2.0 - Frantic: How are properties resolved?
Date Tue, 16 Jan 2001 14:08:56 GMT
----- Original Message -----
From: "Peter Donald" <>

> At 11:40  15/1/01 -0500, James Cook wrote:
> >I dont agree that having a runtime tree (of variables) adds complexity. It
> >is already there in the code now, and it is extremely simple to understand
> >and maintain. It also has the benefit of maintaining scope because it is not
> >flat.
> I am not advocating a flat space - just the appearance of a flat space to a
> task writer (unless they are one of the few who set properties and may need
> to crawl up the tree).

I think the requirements would be:

1. Supply a property system that works in a scoped manner.
2. Property values can be changed and the new property value will be available
to any tasks that are runtime subordinate to the current task.
3. If a property value is changed by a Task, and the lifecycle of the said Task
ends, the property value reverts to its original value.
4. Task developers should be able to declare properties that are global.

> >Keeping it in the engine means that you don't have to pass anything
> >around either. This is patterned after the concepts of an interpreted
> >language or a compiler, so we can feel sure that it works well.
> Okay - now I am confused ;) From what I understand you now have three trees.
> 1. Proxy tree - contains the data required to build the tasks
> 2. Runtime tree - contains the actual task instances
> 3. Data tree - contains the properties, stack trace, etc
> So obviously I have got something wrong. Feel free to correct me ;)

I have two trees...

1. A tree that holds the physical Task structure. This contains Task instances
and its parent-child relationships are the same as the XML file.

2. A tree that gets built on the fly that functions as a stack and holds
property values. This is the HierarchicalHashtable.

> >The execution path of a build script should be open to modification if the
> >user requires it. Why not? If it is not necessary for a particular user,
> >then they don't have to use it. It comes free with the design. I can't
> >imagine why we would want to keep this power out of the hands of the power
> >user if it can be completely transparent to those who don't want to use it.
> Just because you can - doesn't mean you should ;) That would be the
> flexability syndrome. Obviously I don't understand your design thou so I
> could be wrong but it seems the only reason you need the runtime tree (as
> defined in 2 above) is so you can do this. If you didn't need this then you
> could do away with tree 2 all together ...

Ant is being pulled in quite a few directions by ppl who *want* to modify
runtime characteristics. They are doing this via the <if> tasks and the <select>
tasks. Also they want this functionality in the <script> task, so I think that
it is a no-brainer. I contend that it is better to incorporate this type of
flexibility now, at design time, rather than shoehorning it in at a later time.
As you guys can atest to! :-)


View raw message