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 Tue, 27 Nov 2001 01:41:22 GMT
Ok, I've come around on this thanks to these discussions and comments from
Steve and Peter.  Immutable it is.  I'll work on patching this up similar to
Steve's suggestions in the next few days.

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

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?

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

    <tstamp>
    <condition>
    <available>
    <checksum>
    <exec>
    <pathconvert>
    <uptodate>
    <junit>
    <p4change>
    <p4counter>

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.

<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)?
Actually, what will the difference between regular properties and user
properties be if regular properties truly become immutable?

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.

Thanks,
    Erik


----- Original Message -----
From: "Peter Donald" <peter@apache.org>
To: "Ant Developers List" <ant-dev@jakarta.apache.org>
Sent: Monday, November 26, 2001 3:19 PM
Subject: Re: <available> / <condition> breaking immutability


>
> I consider it broken that these tasks break imuttability and usually I
would
> have no problem killing that "feature". However Diane has occasionally
> recomended that on ant-user as a way to get around immutability so ... not
> sure.
>
> I would prefer not to change available to be more inconsistent with
standard
> proeprty behaviour ...
>
>
> On Tue, 27 Nov 2001 04:39, Erik Hatcher wrote:
> > So, just to get clarification -
> >
> > You are ok with <available> (and other such tasks that currently
overwrite
> > properties) unsetting properties if the condition fails?
> >
> > That is my preference simply because it makes sense.  If overriding a
> > property is necessary, the -D switch will do it so only builds that were
> > relying on strange effects would be breaking, I think.  Or ones that
relied
> > on the existence of a property even after a failed <available>.
> >
> > 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.
> >
> > Thanks,
> >     Erik
> >
> >
> >
> > ----- Original Message -----
> > From: "Stefan Bodewig" <bodewig@apache.org>
> > To: <ant-dev@jakarta.apache.org>
> > Sent: Monday, November 26, 2001 9:01 AM
> > Subject: Re: <available> / <condition> breaking immutability
> >
> > > On Sun, 25 Nov 2001, Erik Hatcher <jakarta-ant@ehatchersolutions.com>
> > >
> > > wrote:
> > > > why does <available> and <condition> (and <uptodate>,
<tstamp>, and
> > > > some others) break non-user property immutability?  Is this
> > > > inadvertent or intentional?
> > >
> > > inadvertent AFAIK.
> > >
> > > > I'm (mostly?) of the opinion that <available> and such tasks that
> > > > set a property based on some condition should force the
> > > > setting/unsetting of the specified non-user property.
> > >
> > > I can follow you here - of course this would be breaking backwards
> > > compatibilty (sigh), but I'd consider builds that relied on
> > > <available> not doing what it is supposed to do broken.
> > >
> > > Stefan
> > >
> > > --
> > > To unsubscribe, e-mail:
<mailto:ant-dev-unsubscribe@jakarta.apache.org>
> > > For additional commands, e-mail:
<mailto:ant-dev-help@jakarta.apache.org>
>
> --
> Cheers,
>
> Pete
>
> The big mistake that men make is that when they turn thirteen or fourteen
and
> all of a sudden they've reached puberty, they believe that they like
women.
> Actually, you're just horny. It doesn't mean you like women any more at
> twenty-one than you did at ten.                --Jules Feiffer
(cartoonist)
>
> --
> To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>
>
>


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