ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@apache.org>
Subject Re: [myrmidon] CVS move
Date Tue, 16 Apr 2002 11:46:43 GMT
On Tue, 16 Apr 2002 15:42, Adam Murdoch wrote:
> >     b) Ant/AntCall can setup listeners, references and TaskDefs which
> > should be passed to the executed target.
> > I was thinking of introducing a ContainerContext (or ExecutionContext?)
> > which can be passed into the Embeddor, which could create a child context
> > for each workspace, which could then create a child context for each
> > Project execution, and so on... This should make it easier to introduce
> > scoped properties as well.
>
> ExecutionContainer should work fine for supplying the Embeddor with the
> root ExecutionFrame (property store, services, and logger), from which all
> other ExecutionFrames inherit.  The embeddor would supply the missing bits
> (e.g it would create, say, a default configurer if one was not supplied to
> it).
>
> 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

> - 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).

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

-- 
Cheers,

Peter Donald


--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message