ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Murdoch <adammurd...@apache.org>
Subject Re: [myrmidon] CVS move
Date Tue, 16 Apr 2002 05:42:02 GMT
On Tue, 16 Apr 2002 14:17, Darrell DeBoer wrote:

> > * move across the ant1compat layer.
>
> It looks like this is now moved, but I don't imagine that it's functional.
> I'll have a look at it in the next couple of days. (Hopefully, I can
> reuse/extend the build templates that Adam is working on, but I haven't had
> a chance to look at it yet).
>

Give it a day or two - I'm just in the middle of gutting the template and 
redoing it.  So it might be a good idea to stick with the build.xml for the 
time being, until I get the templates to the point where they do everything 
that the build.xml's do (including, of course, building the ant1compat lib), 
at which point we can look at cutting over.

> After that, I plan to work on 2 things:
> 1) GUMP run using Myrmidon. I've managed to get a regular GUMP run going;
> now it's time to try it out using Myrmidon.
>
> 2) Refactor the passing of "context" from the the Embedding app ->
> Workspace -> Project Execution -> Task, so that:

I made a bit of a start on this, 'cause I got sick of everything being a 
string.  In particular, have a look at ExecutionFrame (which is now more 
general than it was), and ExecutionContainer.  They were intended to be used 
for this kind of stuff (whether they do, or not, is another question).

>    a) An app hosting Myrmidon has more control over setting up the
> environment which is inherited by Embeddor (current only has Parameters, me
> thinks?)

Kinda - An Avalon Context is used to supply the container config (which is now 
handed to the workspace and all the components it creates), and a Map for a 
workspace's root properties.

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

- Execute a target from a project, in an execution frame that inherits from 
the task's execution frame.

- Execute another task in an execution frame that inherits from the task's 
execution frame.

- Execute another task in the same execution frame as the current task.

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

We want to allow an application (ie something that is embedding ant) to:

- Execute a target from a project, in an execution frame that inherits from 
the root execution frame.

- As for tasks, the application needs to control what ends up the execution 
frames:
  - A set of properties that override the inherited or default properties.
  - A set of services that override the inherited or default services.
  - A logger.

I've left out talk about workspaces and executors and such, because I think we 
might want to spin up a new set of service interfaces which the tasks would 
use. 

We also need to decide how listeners are going to work.  We should probably 
move them out of workspace, and generalise into some kind of event 
infrastructure.


-- 
Adam

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