ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Murdoch <>
Subject Re: [myrmidon] CVS move
Date Tue, 16 Apr 2002 12:46:26 GMT
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 

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


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

View raw message