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 Thu, 29 Nov 2001 02:15:27 GMT
Ok, I'm into these modifications, and just wanted to report on the

----- Original Message -----
From: "Peter Donald" <>
> > 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
> so. It will get really annoying and hopefully users will "choose" to
> to use the supported approach.

*whew* - I just read this during my reply - I had put a message for all
setProperty calls, and was going to report that its really nasty on the Ant
build.xml because of all the warnings from <available> - but I'll make it
only display if overriding an existing property.  :)

> > We should deprecate Project.unsetProperty also, right?  I did a search
> > 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 ;)

If Stefan can refactor his test case to not use it then we can axe
unsetProperty altogether.

> >     <tstamp>
> fix.

Done.  And I'm adding the prefix="..." attribute as suggested also - this
will add the prefix + "." to all property names created (including any by
<format> sub-elements).

> >     <condition>
> fix.


> >     <available>
> leave but issue annoying warning

Done... but can't we just "fix" this one too?!  :))

> >     <checksum>
> fix.


The other tasks I still haven't gotten to.

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

I'm making test cases for all the ones I'm modifying.  XP-style.... write
the test case first, watch it break, then modify the code and watch it pass!

> > <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


I should be done with the major changes shortly and will post the patch for
all to review.


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

View raw message