Hi, I've been enhancing karaf feature/kar handling and thinking more about how to move away from some of our proprietary stuff so I thought I'd mention what I'm trying out.
Right now we have a PersistentConfigurationList that keeps track of the configurations/plugins we've installed. There are several other mechanisms to do this in karaf and osgi so we should use one or more of these instead of ours. IIUC karaf has stuff installed into system that is started from startup.properties and stuff that's just installed into the framework. If you do a framework clean start the stuff from system/startup.properties still gets started but anything else you've installed into the framework must be reinstalled by some other mechanism. I've made the karaf karaf-assembly packaging by default install kars into system and add the feature bundles to startup.properties, so anything in an assembled server will be started automatically. I think this is going to be enough support for starting things in the right order, now done by dependencies. For individual configurations, once you strip out the dependency management, all you need is a simple extender that loads gbeans when the bundle is resolved and starts them when it's started. I think this will mean we can just drop ConfigurationManager and DependencyManager. Currently the javaee related builders are adding the runitime plugins as dependencies to configurations during deployment so that the gbean classes can be loaded. However, we are already using a "multibundle" for this in some cirbumstances, namely wab deployment. To replace the dependency based approach I'm planning to register some of the runtime bundles as services with appropriate service properties and look them up using filters when a Configuration starts. By separating the feature-like "install a bunch of things at once" aspect from the gbean Configuration aspect of "start a bunch of services" we'll need to duplicate the configs as features/kars. As we move away from gbeans most or all of the config projects will become unnecessary. I'm doing this work locally in git which makes it pretty easy to keep up with trunk changes. If anyone is interested in seeing my gradual progress I can try to get something out on github although my previous attempts to do this haven't worked for long, AFAICT the git svn rebase needed to keep up with trunk is incompatible with git push remote. thanks david jencks
