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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
