ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Conor MacNeill <>
Subject Re: Order of attributes versus elements
Date Sat, 02 Mar 2002 14:09:23 GMT
Stefan Bodewig wrote:

> This is what the "Developing with Ant" document says as well, see
> points 6 and 7 in the "Life cycle" list.

OK, hadn't read that in a while. I don't think it is true for top-level 
tasks (property, taskdef), is it? Anyway they are small enough to handle.

> Right now it does give that guarantee, I'm not sure whether it should
> do.  What Ant should do is exactly define the order by which children
> are created and attributes being set - and then stick to it.


> So, I think Ant should give guarantee some behavior, which order is to
> be preferred may be open for discussion in the Ant2 context, but not
> really for Ant1.
> Do you think the order is wrong?

I find it more natural the other way around. Actually if you think about 
addConfigured, in that case it is actually the other way around - 
attributes get set first.

>>Actually my expectation was that Ant1 would also set attributes
>>first but the RuntimeConfigurable comes into play. Interestingly
>>attribute setting is deferred to runtime but nested element creation
>>is not.
> For the same reasons as task instantiation is not deferred - make the
> id available for others.

Ah, OK. Unfortunately this particular behaviour makes it very difficult 
to replace a built-in task with an enhanced version. Consider the 
following build file

<project default="test">
   <target name="test">
     <taskdef name="echo" classname=""/>
     <echo file="build.xml" tofile="test"/>
     <mkdir dir="temp"/>
     <echo todir="temp">
       <fileset dir="." includes="build.xml"/>

That doesn't work in Ant today, although if I comment out the second 
echo it will work.

The ids don't seem that useful anyway. If they refer to a non top-level 
object it probably won't have been configured anyway unless it has been 
evaluated. I feel perhaps we should just move to always using 
UnknownElement for non-toplevel tasks. That would do away with all the 
task invalidation hack.

BTW, If you use a nested id today, you actually get a warning about a 
reference being redefined because the maybeConfigure step re-does the 
reference. Probably should get rid of that.

What a tangled web we weave :-)

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message