ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Hatcher" <>
Subject Re: <available> / <condition> breaking immutability
Date Mon, 26 Nov 2001 17:39:54 GMT
So, just to get clarification -

You are ok with <available> (and other such tasks that currently overwrite
properties) unsetting properties if the condition fails?

That is my preference simply because it makes sense.  If overriding a
property is necessary, the -D switch will do it so only builds that were
relying on strange effects would be breaking, I think.  Or ones that relied
on the existence of a property even after a failed <available>.

What backwards compatibility issues will we have?  Are the other committers
on board with this change?  I don't want to go to the effort of patching
these things if its not an acceptable change.  I'm not sure when/if I'll get
around to patching it, but this seems like an important issue.


----- Original Message -----
From: "Stefan Bodewig" <>
To: <>
Sent: Monday, November 26, 2001 9:01 AM
Subject: Re: <available> / <condition> breaking immutability

> On Sun, 25 Nov 2001, Erik Hatcher <>
> wrote:
> > why does <available> and <condition> (and <uptodate>, <tstamp>,
> > some others) break non-user property immutability?  Is this
> > inadvertent or intentional?
> inadvertent AFAIK.
> > I'm (mostly?) of the opinion that <available> and such tasks that
> > set a property based on some condition should force the
> > setting/unsetting of the specified non-user property.
> I can follow you here - of course this would be breaking backwards
> compatibilty (sigh), but I'd consider builds that relied on
> <available> not doing what it is supposed to do broken.
> Stefan
> --
> To unsubscribe, e-mail:   <>
> For additional commands, e-mail: <>

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

View raw message