> -----Original Message----- > From: Peter Donald [mailto:[EMAIL PROTECTED]
> > > * 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
