ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Conor MacNeill <co...@cortexebusiness.com.au>
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="org.apache.tools.ant.taskdefs.Copy"/>
     <echo file="build.xml" tofile="test"/>
     <mkdir dir="temp"/>
     <echo todir="temp">
       <fileset dir="." includes="build.xml"/>
     </echo>
   </target>
</project>

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 :-)
Conor


--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message