ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Conor MacNeill <>
Subject Re: [Ant2] scoping of properties
Date Mon, 22 Oct 2001 13:15:11 GMT
Stefan Bodewig wrote:

> This is not about the mutability of properties.  We'd need a separate
> thread here and I don't want to start too many on one day, especially
> after four months of silence 8-)
> When I say properties in the subject, I'm actually talking about data
> types in general as properties will only be a special case of data
> types in Ant2.
> Possible scopes for properties:
> (1) Hierarchical scope - properties that are available everywhere in
> the build file that defines them as well as in all subbuilds that are
> invoked from this buildfile (and subbuilds invoked from subbuilds and
> so on).  This basically is the Ant 1.x model, as long as we leave the
> inheritall attribute of <ant> aside.

I don't think properties should be passed to subbuilds at all except as 
explicit <param> elements. Passing the whole environment just asks for 
namespace collisions. If you were trying to stitch together a set of 
independent builds this coould be a nightmare. The fact that many builds 
use the same names as a sort of buildfile pattern just exacerbates this.

> (2) Global scope - properties that are available throughout the whole
> build process.  The difference to (1) would be that subbuild defined
> properties could be accessed in the parent build file.

-1. Apart from the problems of having a sub-build affecting the parent 
which feels wrong, this is subject to the same namespace collisions as (1).

> (3) Build file scope - properties that are available everywhere in the
> build file that defines them, but not in subbuilds - this is Ant 1.x
> with inheritall="false" on <ant> tasks.

+1, with the addition of peers from projectrefs as discussed by Peter. I 
see we have a new syntax, there, Peter :-)

> (4) Target scope - properties that are available only in the target
> that defines them.

Probably OK - we need to consider the immutability issues, soon, though 
to know how this would really work. I would argue that  we would still 
have an enclosing buildfile scope (populated by top-level tasks/types/blah).

> (5) Container scope - even finer grained than (4) for things like
> <parallel> or similar.

Would probably drop out of implementing (4) anyway.

We need to define the scope of command-line properties. ie. (3) is still 
a hierarchy. Command line overridability is pretty essential for a build 


View raw message