[DISC] passing properties to subbuilds

[Stefan Bodewig <bo...@apache.org>]

OK, just to get a basis to implement the same feature for Ant1 - we'd
have to sort out details for the non-property data types for Ant2
(i.e. how to define them).

The same rules apply to <ant> and <antcall>.

Conor's approach (as I've understood it):

We add a new attribute explicit to <ant> that defaults to true in Ant2
but false in Ant1 - if this one has been set to true, only those
properties that are set via nested <param> elements will be passed to
the sub build.

All properties that get passed to the sub build override the properties
with the same name in the sub build.

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> - with one
exception: you can say that you are just giving a default value for a
property that should not be used if that property already exists.

I see a problem with Jose Alberto's approach as it is sure going to
break Ant1 build files that hold multiple definitions of properties
and rely on the fact, that only the first definition will win (Ant's
own build file for example uses a property file to override
build.compiler settings if the user wants to).

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.

Stefan

Re: [DISC] passing properties to subbuilds

[Stefan Bodewig <bo...@apache.org>]

Glenn McAllister <gl...@somanetworks.com> wrote:

> Stefan Bodewig wrote:
> 
>> OK, just to get a basis to implement the same feature for Ant1 -
>> we'd have to sort out details for the non-property data types for
>> Ant2 (i.e. how to define them).
> 
> Off the top of my head, I'd be inclined to say that whatever rules
> we use for properties applies for the other data types as well.

Sure.  What I wanted to say: you can pass properties using the nested
param tag, but we don't have a way to pass (possibly user-defined)
data types yet.

> And if the value is false, everything from the parent gets passed
> through overriding the sub build values (reflecting the current
> behaviour)?

Exactly.

> However, this is going to hose compatibility between Ant1 and Ant2.
> Everyone is currently assuming when they call the sub build, the
> parent values take precidence.  With Ant2, *none* of the parent
> properties are going to be passed by default; any sub build that
> depends on getting a value from the parent will now break.

Shouldn't be a problem - we've already promised to provide some kind
of build file converter with Ant 2.  This one could simply insert an
explicit="false" in all <ant> tasks.

Stefan

Re: [DISC] passing properties to subbuilds

[Stefan Bodewig <bo...@apache.org>]

Peter Donald <do...@apache.org> wrote:

> We can still use XSLT to *fix* this when we create an Ant1 to Ant2
> XSLT sheet ;)

We can still use whatever tool we like - including an Ant task - when
we create this Ant1 to Ant2 migration tool ;-)

Stefan

Re: [DISC] passing properties to subbuilds

[Peter Donald <do...@apache.org>]

At 12:31 PM 6/12/01 -0400, Glenn McAllister wrote:
>> Conor's approach (as I've understood it):
>>
>> We add a new attribute explicit to <ant> that defaults to true in Ant2
>> but false in Ant1 - if this one has been set to true, only those
>> properties that are set via nested <param> elements will be passed to
>> the sub build.
>>
>> All properties that get passed to the sub build override the properties
>> with the same name in the sub build.

+1 on this approach as it seems to make the most sense to me. Simplest
approach that still provides functionality (and simple to implement to boot).

>And if the value is false, everything from the parent gets passed through
>overriding the sub build values (reflecting the current behaviour)?  I'm
>cool with this approach; I'm much happier being explicit rather than
>implicit.
>
>However, this is going to hose compatibility between Ant1 and Ant2.
>Everyone is currently assuming when they call the sub build, the parent
>values take precidence.  With Ant2, *none* of the parent properties are
>going to be passed by default; any sub build that depends on getting a
>value from the parent will now break.

We can still use XSLT to *fix* this when we create an Ant1 to Ant2 XSLT
sheet ;)



Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*

Re: [DISC] passing properties to subbuilds

[Glenn McAllister <gl...@somanetworks.com>]

Stefan Bodewig wrote:

> OK, just to get a basis to implement the same feature for Ant1 - we'd
> have to sort out details for the non-property data types for Ant2
> (i.e. how to define them).

Off the top of my head, I'd be inclined to say that whatever rules we use
for properties applies for the other data types as well.  We do that now
for taskdefs and typedefs in Ant1 under the covers, so we should keep it
consistent.

> The same rules apply to <ant> and <antcall>.

yep.

> Conor's approach (as I've understood it):
>
> We add a new attribute explicit to <ant> that defaults to true in Ant2
> but false in Ant1 - if this one has been set to true, only those
> properties that are set via nested <param> elements will be passed to
> the sub build.
>
> All properties that get passed to the sub build override the properties
> with the same name in the sub build.

And if the value is false, everything from the parent gets passed through
overriding the sub build values (reflecting the current behaviour)?  I'm
cool with this approach; I'm much happier being explicit rather than
implicit.

However, this is going to hose compatibility between Ant1 and Ant2.
Everyone is currently assuming when they call the sub build, the parent
values take precidence.  With Ant2, *none* of the parent properties are
going to be passed by default; any sub build that depends on getting a
value from the parent will now break.

> 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> - with one
> exception: you can say that you are just giving a default value for a
> property that should not be used if that property already exists.

Hmm... a little complicated, and requires a change in the <param>
element.  Its also not particularly consistent in how it handles
precidence...

> I see a problem with Jose Alberto's approach as it is sure going to
> break Ant1 build files that hold multiple definitions of properties
> and rely on the fact, that only the first definition will win (Ant's
> own build file for example uses a property file to override
> build.compiler settings if the user wants to).

I think no matter which approach we take we are going to break
compatibility between Ant1 and Ant2.

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

Same here.  Its closer to our historical approach of dealing with
properties.

Glenn.

RE: [DISC] passing properties to subbuilds

[Jose Alberto Fernandez <j_...@yahoo.com>]

> From: Stefan Bodewig [mailto:bodewig@apache.org]
>
> Jose Alberto Fernandez <j_...@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
>

Re: [DISC] passing properties to subbuilds

[Stefan Bodewig <bo...@apache.org>]

Jose Alberto Fernandez <j_...@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.

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.

Stefan

RE: [DISC] passing properties to subbuilds

[Jose Alberto Fernandez <j_...@yahoo.com>]

> 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> - with one
> exception: you can say that you are just giving a default value for a
> property that should not be used if that property already exists.
>
> I see a problem with Jose Alberto's approach as it is sure going to
> break Ant1 build files that hold multiple definitions of properties
> and rely on the fact, that only the first definition will win (Ant's
> own build file for example uses a property file to override
> build.compiler settings if the user wants to).
>

This is not exactly what I had in mind. <property> only overrides those
properties that were not defined locally. So, once the property is defined
locally once, it cannot be changed, just as we have today. Remember I one
big supported of inmutability :-).

The default mechanism, allows you to tell <property> to make a non-locally
defined value, local (as the default). Once this is done the property is
considered to be locally defined and hence it cannot be changed.

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

What I tried to accomodate with my definition was the case, pointed out by
Diane, of the ${debug} property to control debug mode on <javac>. 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.

With my approach, each build file would have something like:

	<property name="debug" default="debug" />
	<property name="debug" value="false"/>

if debug is already defined, its value would have been made local (and be
fixed) otherwise if will get the value "false" in the local environment. Of
course the actual sysntax if up for discussion.

Jose Alberto

> Stefan
>