On Tue, 16 Apr 2002 21:46, Peter Donald wrote: > > It might be worth stepping back and looking at the use cases we're trying > > to handle. As I see it, we want to allow a task to: > > > > - Execute a target from a project, in an execution frame that inherits > > from the root execution frame. > > if root == workspace then +1 to this
It wasn't. The root execution frame is the one that the embeddor maintains. Each workspace execution frame inherits from that. Of course, reality doesn't quite reflect that - there isn't a property store in the root context (well, there's an empty one). Eventually, there probably should be. This is where the -D properties and system properties and such would end up. So, this use case covers <ant> and <antcall> where you don't want to inherit anything. I'm not sure we want to execute these in the same workspace as the calling task, particularly where we're already executing the same project there. Or do we? What is a workspace, exactly? > > - Execute a target from a project, in an execution frame that inherits > > from the task's execution frame. > > +1 (though I would prefer to enhance the dependency mechanisms rather than > allow a lightweight "call" task). > This is for <ant> and <antcall> where you want to inherit properties, types, etc. Maybe it should inherit from the project execution frame, rather than the task's execution frame (which are actually the same physical object at the moment)? Speaking of dependency mechanisms, it would be interesting to allow optionally inheriting the target dependency info, so that targets that had completed in the parent execution frame would not be executed again. Then there's the whole async thing. We probably want to start thinking about this, 'cause we're going to need it eventually. If we can come up with a model that lets us add this later, without too much grief, then that's a good thing. > > - Execute another task in an execution frame that inherits from the > > task's execution frame. > > +1 > > > - Execute another task in the same execution frame as the current task. > > +1 > > > - In the first 3 cases, the task needs to have some control over what > > ends up in the execution frame: > > - A set of properties that override the inherited properties. > > - A set of services that override the inherited properties. > > - Replace the inherited logger. > > > > One requirement is that we have to allow the task to do this *without* it > > having access to its *own* execution frame (a rather major IoC > > violation). > > yep. What we could do is add more create() methods into ExecutionFrame or > whatever. Kinda like > > createChildContext(Map properties, Map services, Map logger) > > and if null use current value. That way we are still leaving control in > hands of frame but we can also implement the above things. +1. It's the facade services that are calling this, not the tasks, right? -- Adam -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
