directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Göktürk Gezer <gokturk.ge...@gmail.com>
Subject [ApacheDS 2.0] OSGI, Implementing modularity
Date Mon, 10 Oct 2011 16:38:25 GMT
Package conflicts are almost completely resolved. So we can begin
implementing OSGI modularity into ApacheDS. To pass through the list again,
we must do following:

* 3.th party dependencies must be bundleized. Apache commons that we are
dependent on are already osgi bundles. Some of the remainings are already
bundleized(antlr, slf4j, log4j, mina-core). Some of them are just jar files,
no POM supplied. We must transform and maintain the nonOSGI dependencies by
ourselves. There are not much of them. Bouncycastle is somewhat problematic
with maven-bundle-plugin. I'll do some workaround for it specially.

* Shared libraries are already OSGI bundles, but their usage of OSGI
services in their BundleActivator classes are not designed for OSGI
dynamism. They assume the ApacheDS is one big megabundle(it is now). We're
going to handle that problem with OSGI Start Levels until we start
implementing service layer using IPojo.

* All submodules of ApacheDS will be modified to generate OSGI bundles.

* The existing apachads-service module can be left here, but we'll need new
service implementation that utilize Apache Karaf. New project will create
custom Karaf distribution, which will has all dependencies and all core
bundles to start ApacheDS. And we will custom tailor Karaf's configuration
for our needs.

* At that stage we'll have around 65 bundle to start ApacheDS on OSGI. For
people using our custom Karaf distribution, this will not be a problem. But
for others who want to install ApacheDS on their own, we must provide an
easy mechanism to deploy the ApacheDS without messing with 65 bundles
directly. We'll already have a Karaf Feature Descriptor at that stage for
Karaf users. But we must also provide an OBR repository for our builds.As
abridged version, OBR repository is just an xml file, keeps dependency
information between bundles, so clients can deploy one core bundle using
OBR, and then its dependencies are automatically resolved and deployed by
OBR agent. If Apache have some central OBR repository, we can use that?

* After we completed above steps, we can start implementing services using
IPojo.

Lets talk more about it and elaborate the details. I'm on those steps,
starting tomorrow. I'll let you know the current status regularly.


Regards,
Gokturk

Mime
View raw message