Too eager filterset execution?

[Steve Byrne <sb...@dorado.com>]

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: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org

Documentation v1.6.5

[pa...@yahoo.com.au]

I've looked for an offline version of recent Ant documentation (PDF, ZIPped 
HTML, whatever), v1.6 or later.
Does anyone know where I can get a copy?
Thank you
Peter


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org

Re: Too eager filterset execution?

[Steve Byrne <sb...@dorado.com>]

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!

Steve

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 <sb...@dorado.com> 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: user-unsubscribe@ant.apache.org
>> For additional commands, e-mail: user-help@ant.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
> For additional commands, e-mail: user-help@ant.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org

Re: Too eager filterset execution?

[Dominique Devienne <dd...@gmail.com>]

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 <sb...@dorado.com> 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: user-unsubscribe@ant.apache.org
> For additional commands, e-mail: user-help@ant.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org