ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Duncan Davidson" <>
Subject Re: Some Thoughts on Ant 1.3 and 2.0
Date Tue, 31 Oct 2000 06:15:14 GMT
On 10/27/00 8:43 AM, "Samuel R Listopad II" <>

> I like the scope idea,  however why not use that to make mutable properties?
> i.e.  my ant right now is modified so that in the property itself it has a
> boolean called overwrite which if true will overwrite what ever was there, but
> if not (as in all situations now) it will leave the property untouched.
> However if you added the scope to that........

But -- if you can mark things as "unmutable" in the parent and somebody
tries to set it in the child, but it doesn't succeed -- you have a case
where the user is possibly thinking that one thing is going on, when
actually he is getting bitten by something else.

> The second thing I would like to say is there anyone who has spoken of (I
> haven't seen it) having properties processed at read time?  THe reason I ask,
> and I know this may be shot down as most don't see it useful (at least most
> people I've talked to),  is I think it would be good to have a property like
> output set to '/usr/${currUser}' and then when using ${output} and currUser
> set to alice it would resolve to /usr/alice rather than the /usr/${currUser}
> that it is now (if output defined before currUser). Obviously this goes along
> with mutable properties since it wouldn't make much sense if the inner
> property couldn't change. However it also gets rid of some position
> dependencies (or was this intentioned?)

Properties should be evaluated right as they are being fed into the task
reflection. This allows scripting to work right -- and fixes this problem.

Of course, there is another question here that isn't explicit: When a script
or task of a child build is modifying a property -- is that modification
local or global? Or does it depend if the property came from the local build
or the parent build?

James Duncan Davidson                              
                                                                  !try; do()

View raw message