ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Byrne <>
Subject Re: Too eager filterset execution?
Date Thu, 22 Jun 2006 17:55:31 GMT
Ok.   I guess I understand the reasoning behind capturing the IDs, but I
am not sure I follow the logic of trying to interpret the references
(i.e. the filefilters) when copying the references.  Shouldn't the
references just be held in an unevaluated state?  I.e. any variable
substitutions cannot be done until execution time, and so should be just
copied verbatim?  If that is the case, then why are the filefilter
elements being evaluated when the references are copied?   I think they
should not be being evaluated until they're actually in a context where
the parameter substitutions make sense -- or am I just not somehow
getting it?

I'll try hunting up the "name" reference thing and see if that will
solve my problem.

Thanks for your response!


Dominique Devienne wrote:
> I'm afraid that this is working as designed, although I'm surprised it
> works in 1.5.4 to tell the truth...
> Regarding 1.6.x, <ant> reparses the build file that's executed. Unlike
> everything else in Ant nowdays, the special id attributes are
> processed *at parse time* to bind in the reference map (for historical
> and BC reasons). This is why you are seeing that your types defined in
> non-executed targets are visible nonetheless, even though they were
> not properly initialized.
> To work around this issue, I've put somewhere in bugzilla a
> <reference> type, which allows you to add a reference by 'name'
> instead of 'id'. Not ideal, but would get you going.
> Now why does it work in 1.5.4? I don't know... I 1.5.4, a lot more
> processing happened at parse time, and not everything was first
> created as an UnknownElement like now.
> My only guess would be that somehow 1.5.4 didn't override an existing
> reference when processing (at parse time) the id attributes, while
> 1.6.x would. But that's a wild guess really.
> I hope this helps shed some light on this. --DD
> On 6/21/06, Steve Byrne <> wrote:
>> Hi all.
>> I have a rather convoluted situation that I think is exposing a bug in
>> 1.6.5.
>> Basically, from my main build script, I invoke a custom task that I have
>> written.  During the course of the execution of the task, it creates a
>> CallTarget and calls a target back in the main script.  The main script
>> THEN uses the "ant" task to invoke a target in some other build file.
>> This latter invocation fails.
>> I am setting inheritRefs to true for both the CallTarget and the "ant"
>> task.  The main build script contains several filtersets with "id"
>> attributes set.  Even though these filterset are defined within targets
>> that are not being executed, I can see as the other build file's project
>> is being prepared, the filtersets are being "interpreted", and there are
>> warning messages (during verbose execution) about properties in the
>> filtersets that are not defined.
>> The REAL problem is that in one of the filtersets (again, this is
>> defined in a target that has NOT been executed, and so should be totally
>> ignored), there is a filtersfile element, which refers to a file that
>> does not exist yet, and THAT causes the build to fail.
>> This code works perfectly under 1.5.4.  I believe that the filterset
>> references should NOT be being copied by the "ant" task, since they have
>> not been legitimately created yet, since the targets they are defined in
>> have not been executed.
>> What say you?
>> Steve
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message