On Tue, 27 Nov 2001 19:08, Stefan Bodewig wrote: > On Tue, 27 Nov 2001, Peter Donald <[EMAIL PROTECTED]> 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 ! ;) -- Cheers, Pete "abandon all hope , ye who enter here" - dante, inferno -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
