ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: [Ant2] scoping of properties
Date Fri, 19 Oct 2001 23:06:05 GMT
On Fri, 19 Oct 2001 23:21, 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 see a need to distinguish between this and (3) because <ant/> is a 
task and we can always change that.

> (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.
> (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.
> (4) Target scope - properties that are available only in the target
> that defines them.
> (5) Container scope - even finer grained than (4) for things like
> <parallel> or similar.
> Are there other scopes?  Which of these do we really need?

(6) Access of "peer" projects proeprties. Where a "peer" is defined via a 
<projectref/> tag. So if we define project "jasper" should we be able to 
access a property like "jasper::dist.dir"/"jasper->dist.dir"

Personally I think I most prefer (1)/(3) because that is how we have it now 
and thus it would be less of a steeper learning curve. Though I can be 
convinced of other approaches I suspect.

(6) is interesting though it would be incredibly difficult to use because 
ordering of executions can be difficult to guage and thus it is relatively 

However there is one other thing I have thought about a bit. We allow a 
"controller" build file that sets up a "workspace" and then executes projects 
in that workspace. Maybe something like

<!-- of course we would need to choose a specific access format -->
  <target name="build" project="foo" buildfile="src/make/foo.ant"/>
  <target name="meep::build" buildfile="src/make/meep.ant"/>
  <target name="beep->build" buildfile="src/make/beep.ant"/>
    <property project="foo" name="bar" value="baz"/>
    <property name="meep::moop" value="mop"/>
    <property name="beep->boop" value="bop"/>

So this would execute three targets in one workspace and using one DAG (ie 
the same target could not be called again across whole set of projects in 
workspace). Is the above clear? 

If so - do you like it ? This would finally solve all the issues that have 
been raised so far about controlling etc.



Which is worse: Ignorance or Apathy? Who knows? Who cares?

View raw message