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 Tue, 27 Nov 2001 10:51:12 GMT

----- Original Message -----
From: "Peter Donald" <>
> On Tue, 27 Nov 2001 12:41, Erik Hatcher wrote:
> > I really was thinking that if <available> was checking for something,
> > 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
> on whether the property gets set or unset.

Yes, I also considered the argument going that far too!  :)

> Heres my opinion...
> >     <available>
> leave but issue annoying warning

Ok.... is this just to maintain the backwards compatible "back door"?

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

I'm sure the use-case is just to set a path to a different operating systems
format.  This could easily be dealt with by using different properties for
each path rather than relying on overriding one.

> >     <uptodate>
> >     <junit>
> >     <p4change>
> >     <p4counter>
> leave but issue annoying warning

Ok.  I suspect some folks might rely on the behavior of <junit>, run a
series of tests and put them all to the same error or failure property, then
do something based on the value of that property.  The way to get around
that would be to have them all go to separate properties, then do a
<condition> on them all to set a single property.

> > <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
> ... 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
> > to be 100% sure of how this should be done if/when changes are made.
> works for me.



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

View raw message