ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject RE: Proposed Revolution: AntEater (a proposal for Ant Core 2.0)
Date Tue, 14 Nov 2000 06:51:29 GMT
At 10:45  13/11/00 -0800, Jose  Alberto Fernandez wrote:
>> But Ant needs that anyway if you want runtime interpretation 
>> which is I
>> think what has been decided. I don't think we should go to 
>> the extent of
>> thread safe implementations protected by 
>> monitors/synchronized blocks but
>> we do need to dynamically interpret the original form if we are to do
>> things like
>> <mytask myattr="${myVar}"/>
>This is done by ANT today, and this does not represent a change unless
>you want to be able to do:
>  <mytask myattr="${myVar}"/>
>  <property name="myVar" value="newvalue" />
>And now you expect that somehow the text execution of the target containing
><mytask> will execute with the new value for "myVar".

yep exactly what is wanted. In some cases it is not possible to determine
the value of a variable until runtime which I think is something that was
agreed upon as a desirable feature.

>Even if we allow that, I have no problem.

me neither ;)

>What is a problem is for the GUI to replace <mytask ..../> with <yourtask
>and expect ANT to keep on ticking. This is to me what "editing" a project
>and I do not want ANT to need to keep track of all that.

agreed - that is a horrible abuse as is doing it through scripting.

>A worst case occurs with the usage of UnknownElement in ANTs representation
>express tasks not known at parse time. They are replaced by the actual task
>during execution (a form of chaching). Now how do we expect to swap this
>and let the GUI know that the taks previoulsly represented by the
>UnknownElement class
>has been replaced with this other class.

Personally I don't think we should ever use UnknownElement ;) I think it
should be a tree that is interpreted at runtime and thus transformed into
repective objects and executed.

>Moreover, if I now go and edit the <taskdef> for that task, now I need to
>the node i the GUI again during the next execution. I think this is quite

I agree ;) Thats another reason why we should have a static Dom-like tree
that is dynamically interpreted ;)

>The best is to keep the two representation separate. 

right. However it just happens that the requirements for both different
tools GUI/Ant with dynamic interpretation are the same. I agree that we
should not allow modification of the tree at runtime (by either the GUI or
scripts) but I can not think of a good reason not to use the same
representation. Playing with model at runtime is unsupported and never
guarenteed to work (or preferably blocked in some manner) ;) 



| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power."          |
|       -Abraham Lincoln                               |

View raw message