ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jose Alberto Fernandez <>
Subject RE: Proposed Revolution: AntEater (a proposal for Ant Core 2.0)
Date Tue, 14 Nov 2000 06:45:34 GMT
> From: Peter Donald []
> At 09:02  13/11/00 -0800, Jose  Alberto Fernandez wrote:
> >
> >This is exactly what I think is very very wrong. Lets assume
> >that you have the ability of editing ANTs internal representation
> >of the project. Now that means that any validation or caching
> >that ANT mades to its representation of the project it may be
> >put at risk of inconsistencies because the GUI decided to edit
> >something,for example, in the middle of a run (in some other thread).
> >This would mean a lot of defensive coding just to protect against
> >extrange manipulation of the internal representation.
> 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".

Even if we allow that, I have no problem.

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.

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.

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

The best is to keep the two representation separate. 

Jose Alberto

View raw message