ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Murdoch" <>
Subject RE: [myrmidon] api.metadata.Model*
Date Sat, 23 Mar 2002 00:57:42 GMT

> -----Original Message-----
> From: Peter Donald []

> > * A few of the framework interfaces are used in myrmidon.interfaces.
> > (Logger, Parameters, ServiceManager, Parameterizable, etc).  
> Nothing major,
> > I don't think.
> okay - I guess framework will have to stay in common classloader 
> - ohwell. I 
> knew it couldn't be this easy.

It's really only the Logger interface that we need.

The other usages:

* AspectManager uses Parameters.  AspectManager is getting axed, right?

* Deployer.createChildDeployer( ServiceManager ).  The param isn't being used in DefaultDeployer,
and we can change the contract of createChildDeployer() so that the returned Deployer is service()'d
by the caller.

* Embeddor extends Parameterizable, Initializable, Startable, Disposable.  It shouldn't.

* Embeddor.createProject( String, String, Parameters ).  Change to a Map, or axe.

* Embeddor.createWorkspace( Parameters ).  That should definitely be a Map, now that properties
are Objects.

> Not sure - is it still worth going to Model* rather than Config* 
> ? The only 
> advantage I see is that it is a smaller interface. The 
> disadvantage I see is 
> code duplication and you lose all the getAttributeAs* 
> getContentAs* helper 
> methods - but then again they will only be used by handwritten 
> self-configuring tasks.

And we want to make that as painful as possible :)

A couple more advantages to using Model*:

* Gets rid of the last of the Avalon stuff from the task API.
* It's ours to change as we like.  For example, experimenting with 
  using Objects in the model, rather than Strings.

> I will look at it all again see if I can think of anything else 
> interesting 
> to do wrt all these dependencies. 
> > * framework.factories needs to use framework classes, so we 
> should probably
> > move them to the container classloader too.  Maybe we should unify the
> > services and components.  Certainly things like the Configurer, Executor
> > and PropertyResolver could be loaded from an ant-services.xml 
> descriptor.
> okay. Though as a service is workspace wide, that would mean 
> there could only 
> have one instance of each service. I guess that is fine. 

Actually, right now services are global (shared by all workspaces).  Good enough for now,
but something we might want to change.  What I'd like to do is come up with a general model
that allows a component/service to be inserted at any level (global/workspace/project/target/task).


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

View raw message