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 Tue, 27 Nov 2001 08:47:30 GMT
On Tue, 27 Nov 2001 19:08, Stefan Bodewig wrote:
> On Tue, 27 Nov 2001, Peter Donald <> wrote:
> > On Tue, 27 Nov 2001 18:42, Stefan Bodewig wrote:
> >> From this thread, it seemed we could agree on most parts
> >
> > could you summarize?
> I wanted to put it up for a formal vote once I had a feeling for the
> target scope issue.
> So far you, Conor and I agreed that we needed build file scope and
> make hierarchical scope explicit (with properties set on the command
> line and <param> within <ant>).

So let me get this straight. We have per-Project scope ? Properties can be 
specified before the project is started - lets call this Workspace scope. 
Workspace scope is in effect throughout the whole "execution".

<antcall />, <ant /> start new "executions" and thus you can create a new 
"Workspace" scope with them and this contains all the specied <param/>s.

Is this right so far?

Did we decide whether the current projects "Workspace" properties would be 
accessible after <antcall /> (via it's "Workspace" properties presumably) ?

> And then there is <projectref> - could you expand on this as well
> please.

When I refer to <projectref/> I mean exactly the same thing that it meant 
when it was originally proposed last year and not the many subsequent 
"interpretations". Basically projectref is simply a way for one project to 
refer to another (kinda makes sense eh?) so that it can be included in the 
same dependency graph.

So with that meaning there is nothing that needs modification with the above 
explanation of property scoping. Each project still has their own scope and 
there is still a single "Workspace" scope that they are all in (at least if 
the projects can be reached via a depends attribute).

> > If we wanted we could easily block all possibility of tasks
> > implementing scope unlss they wanted to go to absurd lengths.
> True.
> If we implement TaskContainer (and therefore target) scope inside the
> core, 

yuck ! ;)

> we should do that.  If we leave it to the containers, we leave
> it to the containers. 

Even if we allow containers to be written in "user space" we can block their 
ability to easily implement scopes. All we need to do is have the policy 
implemented in the setProperty method and not provide any getPropertyNames() 
style method.

> I'm trying to collect the pros and cons of both approaches. 

I haven't found any pros yet for allowing it to be up to the task *but* I 
think this is a question we should answer later on in ant2s life when we have 
a working implementation and can test things out. I assume issues will become 
clearer with an implementation in hand.

> TaskContainer scope will of course be needed by things
> like an <iterate> task.

quick lets make propertys immutable then ! ;)



"abandon all hope , ye who enter here" - dante, inferno

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message