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