ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glenn McAllister <>
Subject Re: [DISC] passing properties to subbuilds
Date Tue, 12 Jun 2001 16:31:19 GMT
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

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

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

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

> 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

View raw message