ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Hatcher" <jakarta-...@ehatchersolutions.com>
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
progress...

----- Original Message -----
From: "Peter Donald" <peter@apache.org>
> > 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.

*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
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 ;)

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.

Done.

> >     <available>
>
> leave but issue annoying warning

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

> >     <checksum>
>
> fix.

Done.

The other tasks I still haven't gotten to.

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

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

Done.

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

Thanks,
    Erik



--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message