ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: <available> / <condition> breaking immutability
Date Tue, 27 Nov 2001 07:38:14 GMT
On Tue, 27 Nov 2001 12:41, Erik Hatcher wrote:
> I really was thinking that if <available> was checking for something, that
> it should have the final say on whether the property gets set or unset -
> and I still "almost" think that.  

Thats like saying if you have <property/> task it should have the final say 
on whether the property gets set or unset.

> But having it consistently *immutable* is
> cool with me as long as there is consistency.  Having the API prohibit
> properties from changing is how it should be done, and that is how I will
> implement my patches. 


> But to maintain backwards compatibility with tasks
> that rely on the property mutability, should we just keep
> Project.setProperty as-is and let it change properties?  Should we
> deprecate it though?

deprecate it and then add a check inside it. If you are breaking the 
immutability rules then print out a really really obnoxious 
deprecation/warning message saying "dont use me" possibly spanning 3 lines or 
so. It will get really annoying and hopefully users will "choose" to upgrade 
to use the supported approach. 

> Then we create another method: Project.setNewProperty (String name, String
> value) - the name of this method is up for debate.  I don't think we should
> go with allowing the set/unset option that Steve proposed though - just
> leave properties immutable.  Once set, always set - nice and simple rule.
> Calling setNewProperty will log the "cannot override" warning that
> <property> displays - and we'll delegate <property>'s message up to Project
> then.
> We should deprecate Project.unsetProperty also, right?  I did a search and
> none of Ant's code calls it.  Should we axe it altogether?  Or leave it,
> and deprecate it?

deprecate and print a realy obnoxious message ;)

> Here are some things within Ant's core that rely on property mutability:

Heres my opinion...

>     <tstamp>


>     <condition>


>     <available>

leave but issue annoying warning

>     <checksum>


>     <exec>


>     <pathconvert>

don't know (could someone give me an example use case).

>     <uptodate>
>     <junit>
>     <p4change>
>     <p4counter>

leave but issue annoying warning

> I can't promise I caught them all, but these all call Project.setProperty
> directly without doing a check for the existence of the property first.
> Only <property> does that (maybe something else checks, not 100% sure) -
> but of course something as important as property immutability should be
> under the control of the Project, not the task.

I mostly agree. I have a feeling that this approach will break down in some 
cases but as of yet I can't think of any such case ;)

> <property> - woah, I just discovered it has an undocumented userProperty
> flag!  It won't override a user property, but it will set one.  Thats
> interesting.  Should this become documented?  Or is it hidden to keep
> casual users from fooling around with the power of user properties
> (although that won't make much difference when properties truly become
> immutable)? 

hide, deprecate, issue ugly warning

> Actually, what will the difference between regular properties
> and user properties be if regular properties truly become immutable?

user properties will be propogated to sub-builds even if inheritall="false" 
... I think (without actually looking at code or testing theory but just a 
gut feeling about how it *should* work).

> Let me know if there are any issues with what I'm proposing above.  I want
> to be 100% sure of how this should be done if/when changes are made.

works for me.



I think not; therefore I ain't...

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

View raw message