ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Samuel R Listopad II" <>
Subject RE: Some Thoughts on Ant 1.3 and 2.0
Date Fri, 27 Oct 2000 15:43:05 GMT
> (*) Change of the property system one last time
> No matter what we do, there are still some things that need to be
> resolved and finalized. Mainly
> (1) Master projects overwriting properties in sub projects. Sometimes
> you want this to happen, in other cases you do so by accident. The
> easiest solution that doesn't change the behavior of current build
> files would be something like
> <property name="foo" value="bar" scope="file" />
> for properties that should not overwrite properties of the same name
> in sub builds. If you want to overwrite, use scope="global"
> which would
> need to be the default unless we want to break something existing.
> Alternatively add something like <localproperty> for what scope="file"
> would do.
> (2) Do we want mutable properties or not? Regardless of what we come
> up with, we should document it and stick to it.

Hi,  I know I'm new, and not seen much but I wanted to add my two cents to
this statement.

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

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


View raw message