Thanks Peter
I'll try some code like this at some stage.
> -Original Message-
> From: Peter Reilly [mailto:[EMAIL PROTECTED]
> Sent: 30 August 2007 11:43
> To: Ant Users List
> Subject: Re: refid still not behaving as expected in 1.7.0
>
> You can
Does this mean that bug 36955 should be re-opened, or a new bug created?
> -Original Message-
> From: Peter Reilly [mailto:[EMAIL PROTECTED]
> Sent: 30 August 2007 10:35
> To: Ant Users List
> Subject: Re: refid still not behaving as expected in 1.7.0
>
> The beh
ing, as that sounds
> just what I need.
>
> Is there any way to do what I DO want to do, which is to check whether an id
> has been set?
>
> George
>
> > -Original Message-
> > From: Peter Reilly [mailto:[EMAIL PROTECTED]
> > Sent: 30 August 2007 10:35
OTECTED]
> Sent: 30 August 2007 10:35
> To: Ant Users List
> Subject: Re: refid still not behaving as expected in 1.7.0
>
> The behavior as described in the WHATSNEW is what was
> initially was done. However this broke too many builds - with
> references to out-of-band ids.
The behavior as described in the WHATSNEW is what was initially
was done. However this broke too many builds - with references
to out-of-band ids. So the code was modified to store all the
out-of-band ids and if the reference could not be found, to look up
that and if found to use that reference an
Hi
> One of the significant changes in 1.7.0 was, apparently:
>
> " * Defer reference process. Bugzilla 36955, 34458, 37688.
> However, my version of ANT 1.7.0 (binary download) seems to behave in the
> 'old' way. I have looked in WHATSNEW under SVN, and can see no suggestion
> that there was a
One of the significant changes in 1.7.0 was, apparently:
" * Defer reference process. Bugzilla 36955, 34458, 37688.
This may break build files in which a reference was set in a target which was
never executed. Historically, Ant would set the reference early on, during
parse time, so the datat
