ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <>
Subject Re: <available> / <condition> breaking immutability
Date Mon, 26 Nov 2001 20:29:48 GMT

----- Original Message -----
From: "Erik Hatcher" <>
To: "Ant Developers List" <>
Sent: Monday, November 26, 2001 9:39 AM
Subject: Re: <available> / <condition> breaking immutability

> 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
> on the existence of a property even after a failed <available>.
> What backwards compatibility issues will we have?  Are the other
> 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
> around to patching it, but this seems like an important issue.

I dont know what the right action should be here. "Properties are immutable"
is a simple concept, and easy to remember. "Properties are mostly immutable"
is more complex, as "mostly" needs so much clarification.

Right now we have:
 some conditional tasks overwrite properties when true, but dont unset them
when false

And we should really have either
 conditional tasks set and unset properties based on their true/false state


 conditional tasks can't overwrite existing properties; a warning is printed

I think this one will have to be opened up for some consensual decision

As to how to patch the code, all the tasks in question all use
Project.setProperty(), probably assuming that this code would implement
immutablity, whereas that is really implemented in Property.addProperty for
all but user properties.

It would make sense to refactor the immutability code into the Project class
itself, so that all tasks which set a property could make use of it.
Something like two methods, one for conditional setting and another for

 * set a property if the set flag is true, unset it if false
 * if the property is already defined warn/overwrite
Project.setConditionalProperty(string name, string value, boolean set)

 * set a property, apply current mutability policy
Project.setUnconditionalProperty(string name, string value)

with the refactoring it becomes easier to change the behavior, and future
tasks can use the same api calls to get the same functionality. This
refactoring could also be done before any decision is made on how to treat
the conditional assignments, as now there is just one place to change.


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

View raw message