Steve Loughran wrote:
----- Original Message -----
From: "Colin Sampaleanu" <[EMAIL PROTECTED]>
To: "Ant Developers List" <[EMAIL PROTECTED]>
Sent: Sunday, February 24, 2002 12:54 PM
Subject: bug: Ids from paths not propogated through antcalls unless path is
top-level
Unless I am missing something, there is a bug in Ant 1.4.1 in that ids
from path structures don't propogate (aren't usable) through antcalls,
unless the path structure defining the id is top level. Consider the
following ant script:
actually, toplevel defs arent propagating through antcall either; they are
being re-evaluated when the called target runs
A target should
not know whether it is being called as a dependency or through an
antcall, and I do have a number that are executed both ways
then it should state in its dependencies which targets it depends on to init
paths and things.
There is a bit of a fly in the ointment with doing that though. My init
tasks, which total about 4-5 discreet steps, only get executed once,
because of the fact they use an "unless" attribute which checks an
"initialized" property. If I don't do this, then what effectively
happens is that if I have multiple targets in the dependency chain which
say they depende on init, as well as some other target, init will be
called multiple times, doing a significant amount of work (reading prop
files, etc.) each time, and spewing out the same text each time. I
really only want init to be called once, and it has prooven to be
effective and not problematic except for antcall, which ends up losing
the refs. And in fact, if antcall also lost properties, then there
wouldn't be a problem, because my init targets would also be called
again, after the antcall. The problem is that antcall loses some info,
but not all.
NB, <ant> now has inheritRefs; it seems that antcall should acquire the same
attribute and pass it on to the ant task it uses to do its work. Colin, if
you were to add that (and the tests to verify it works), then your problems
will be solved.
Quite a reasonable requests, which I will try to oblige when I get some
time. I was just hoping there was an easy solution or I was missing
something :-)
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
