You are ok with <available> (and other such tasks that currently overwrite properties) unsetting properties if the condition fails?
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.
I've been following this thread with some interest.
As a user with some moderately complex Build files, I agree with Erik's above comments about "expected" behaviour.
However, I'd actually go one step further. To me, if the property is already set before <available> (and similar tasks) fire, you have a broken build and you should get some sort of fatal error.
The decision has been made that properties are immutable - I have no problem with this (at least they aren't called variables, like they are in XSLT!). So, they really should be immutable and *any* task that changes this should be considered broken.
Just my 2c, Bevan.
-- "Programming is an Art Form that Fights Back"
Bevan Arps (<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]) Senior OO Analyst, ACT Financial Systems
This communication is confidential to ACT Financial Systems (Asia Pacific) and is intended for use only by the addressee. The views and opinions expressed in this email are the senders own and do not represent the views and opinions of ACT Financial Systems (Asia Pacific).
