ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <j_a_fernan...@yahoo.com>
Subject RE: [DISC] passing properties to subbuilds
Date Wed, 13 Jun 2001 11:31:37 GMT
> From: Stefan Bodewig [mailto:bodewig@apache.org]
>
> Jose Alberto Fernandez <j_a_fernandez@yahoo.com> wrote:
>
> >> From: Stefan Bodewig [mailto:bodewig@apache.org]
> >>
> >> Jose Alberto's approach (as I've understood it):
> >>
> >> All properties get passed to the sub build.
> >>
> >> All <property> tasks override existing properties unless these come
> >> from command lines or <param> tags nested into <ant>
>
> > This is not exactly what I had in mind. <property> only overrides
> > those properties that were not defined locally.
>
> OK, I see.
>
> > Remember I one big supported of inmutability :-).
>
> I know, I was sure I must have been wrong 8-).
>
> >> I'd prefer to have explicit control over what I'm going to pass
> >> down to the sub build, so I prefer Conor's approach.
> >
> > Until we have preferences, people want to have some properties that
> > they do not really want to manage explicitly all over the build but
> > they want to be able to modify and to get global effect.
>
> But we will have preferences in Ant2.  I'd still prefer to make this
> explicit, even if it may be (a little?) inconvenient - you can always
> say explicit="false" if you don't want to override anything in the
> sub build.
>

Remember, this is compatible with ANT1 ;-)

In any case, since we do not have a good grasp today on how preference is
going to work, how easy they will be to set up, etc. I wasn't relying on
them too much.

Another good example is the "deprecated" attribute for <javac>. I hate
having that thing switch on. It just clutters the output when looking for
errors. But every now and again  I want to do a build having it on, in order
to check I have not introduced something new.

I would like to be able to achieve this by just passing an option
(-Ddeprecated=true ) or something like that, instead of having to modify
some large preferencefile, back and forth. So, the approach may be useful
even on the presence of prefernces.

An additional argument, of course, is that this mechanism releases the
preasure on needing some syntax for passing types and such in its ANT1
encarnation. Since you are able to see things. I still agree we need to
solve the issue properly in ANT2.

> And maybe grouping properties to sets would make this even less
> inconvenient.
>
> > With my approach, each build file would have something like:
> >
> > 	<property name="debug" default="debug" />
> > 	<property name="debug" value="false"/>
>
> If at all, I'd merge them, something like
>
>  	<property name="debug" default="false" />
>
> If the caller passes in a property named debug it will take
> precedence, otherwise we use the given default value.
>

This is a fine solution for me. I was trying to allow for picking the
default from some other property name, but I think this is much much clear.
I like it.

Jose Alberto

> Stefan
>


Mime
View raw message