At 08:08 15/1/01 -0500, James Cook wrote: >> -----Original Message----- >> From: Peter Donald [mailto:[EMAIL PROTECTED] >> 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?
What I am saying is that task writers should not have to do a getProperty()/getAttribute(). All complexity should be on us the engine writers. So the engine would detect that there is a setFoo() method and automagically convert the attribute into setFoos() parameter type and then call setFoo. >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. Right - but why do you need to separate the too. Neither of AntEater or myrmidon separates them - in effect the "runtime" view is throwaway. You create the object, configure it, execute it and then throw it away. Any "context" information is past on in variables. I think we should probably store the execution stack like yours does but I don't think there is any necessaity to store anything more - or have I mistaken something ? Cheers, Pete *-----------------------------------------------------* | "Faced with the choice between changing one's mind, | | and proving that there is no need to do so - almost | | everyone gets busy on the proof." | | - John Kenneth Galbraith | *-----------------------------------------------------*
