ant-dev mailing list archives

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


> -----Original Message-----
> From: Peter Donald [mailto:peter@apache.org]

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


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