I would like to elaborate the things about OSGI those we've talked with you and Alex here. So that we can have some road map.
With respect to OSGI's 3 layer (modularity, lifecycle and services), we can divide our future efforts into 3 main step. Actually the first and second steps can be merged in one.
Step1 (Implementing Modularity and Lifecycle)
This step will contain mostly configuration changes on POM files.
* As you've told, conflict packages problem must be solved or at least down to a minimum degree. For the situations those are impossible to completely solve that issue, we may look into the "fragments" feature that is designed for practically one bundle backing the other with extra content. However this is not an elegant solution. We must ensure the separation as much as we can.
* After dividing the modules's packages properly, we're gonna introduce OSGI specific instructions into each modules POM, making them an OSGI bundle. And at that point we must introduce ApacheDS's 3th party dependencies as bundle imports into corresponding modules.
* Modify the existing apacheds-service module (or add a new one) for embedding the felix, deploying the core and dependency bundles into it, and then starting the ApacheDS on top of Felix.
* Create a Karaf feature description xml file for deploying ApacheDS into Karaf easilly with all of its dependencies.
This first step is going to be mostly a configuration job. If we are lucky, there won't be much code changes at that step. Considering the fact that ApacheDS's code is designed to be embeddable, we are lucky. It already works as megabundle on all frameworks without modification.
Step2 (Implementing Services)
Using services layer in ApacheDS will give you the runtime extendibility you want. But interacting with service layer may not be the wise choice. To deal with the wildly dynamic nature of the OSGI, we must use some component model on top of services. Considering two mainly used component frameworks, blueprint and IPojo, it seems IPojo is the correct choice. To list my reasons of this choice:
* IPojo lets you describe the component model with annotations. It also accepts xml and also gives you the API to create your own way other than these two.
* Its highly extendable, letting you implement your custom needs without need to change the core IPojo code.
* Field injection feature of it is the perfect way for making existing code to use services with minimum modification.
List goes long...
Listing the things we must do for implementing service layer depends on what we want to do with it. For example we can provide partition implementations as services, so changing the code to see those arriving implementations in the form of implementing bundles and start to use them immediately.
The ability to configure the arriving component's(service's) configuration data inside ApacheDS DIT will be an ease for us, the 3th party component writers and the users. I implemented that feature as test research. It has some issues but not unsolvable, we just have to set the slider between speed and code clarity.
Actual substeps needed for implementing service layer will come out clearly after we decided what aspects needs to be extendable.