ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject Re: <available> / <condition> breaking immutability
Date Tue, 27 Nov 2001 12:00:33 GMT
This discussion is snowballing into changing the entire behavior of ANT beyond
just sticking to inmutability. So a couple of thoughts:

From: "Erik Hatcher" <>

> From: "Steve Loughran" <>
> > > to manually specify <tstamp>?!  :)   - this would actually make life
> bit
> > > easier so you could specify other properties relying on a datestamp
> before
> > > the first <target> declaration rather than having to have an 'init'
> target
> > > do this for you.
> >
> > makes sense, if they had names like, but
> > would they be inherited in <ant>?
> They should be user properties and hence carried forward by <ant>
> automatically.  That seems reasonable to me.

The whole point of inheritAll="false" was, as I remember, the recognition that
a property call, for example, "src" only makes sense with respect to the
local buildfile and that the policy of inheriting all was indeed wrong. In particular
it required every subproject to have to use different property names to avoid
inheritance clashes. inheritall="false" was provided as a way for people to migrate
(because of backward compatibility) so that they could prepare for ANT2 when
the default would be not to inherit. And the reasoning applies the same way to
user properties.

If you now change the meaning of inheritall, by allowing some to be inherited and some not,
then we will be breaking this thing once again. Please do not change the meaning of
inheritall="false". If people want to pass values they can pass them as parameters.

> > (*)hey, maybe, just maybe, we could make <tstamp> a sibling of target :-)
> I thought of this also.  I'm not sure if one or both of these things should
> be added or not.  I like the implicitly provided time stamps, but allowing
> the user to define a custom date outside a target is a good thing also.  Any
> reason not to add <tstamp> to the "special" tasks that can be outside
> target?

Never mind that it will require changing the parser, just because we havent being able
to agree on a way to declare which tasks should be allowed as siblings and which not.
We continue to have this patch work of features that half work in a consistent manner.
Well enough rumbling for a tuesday morning ;-)

Jose Alberto

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

View raw message