----- Original Message ----- From: "Bevan Arps" <[EMAIL PROTECTED]> To: "Ant Developers List" <[EMAIL PROTECTED]> Sent: Monday, November 26, 2001 11:45 AM Subject: Re: <available> / <condition> breaking immutability
> 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. I dunno about fatal error, but it reporting it at the MSG_WARN level may make sense -if the assignment was to have been different. That way if you have a child build file that checks for junit.available and the parent did already, then all is well. > 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. I think they probably have been broken, but nobody noticed till now. That is, unless people have been using these tasks for the purpose of overwriting properties without letting on... > 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). So what is the official ACT Financial Systems (Asia Pacific) stance on property immutability in ant then :-) -Steve -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
