This discussion is snowballing into changing the entire behavior of ANT beyond just sticking to inmutability. So a couple of thoughts:
From: "Erik Hatcher" <[EMAIL PROTECTED]> > From: "Steve Loughran" <[EMAIL PROTECTED]> > > > to manually specify <tstamp>?! :) - this would actually make life a > 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 ant.build.today, ant.build.tstamp. 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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
