directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: [OSGi] Implementing OSGi for 1.5
Date Sat, 10 Feb 2007 03:28:27 GMT

Doing this means committing to OSGi and I'm not going to be too 
comfortable with doing this until I see:

(1) some good "in situ" integration testing framework that allows us to 
easily test services within the target container as part of the maven 
build process,
(2) good test coverage, testing the integrated system of ApacheDS 
services running inside an OSGi container (you need #1 for this)
(3) solid documentation in confluence for this OSGi based architecture 
for ApacheDS
(4) Felix graduating with a 1.0 release that has full support for R4 
(and has things like it's plugin deployed to Ibiblio so we don't have 
Maven hick ups with SNAPSHOT plugin artifacts),
(5) greater team awareness of this OSGi based architecture,
(6) more consideration for OSGi alternatives like xbean,
(7) and time for us all to be involved to make sure something does not 
go wrong during this move to OSGi.

#1 can be accomplished by the time #4 occurs through the Felix 
community.  #2 and #3 are up to you and Enrique.  #4 will probably 
happen soon.  IMO the big problems are #5, #6 and #7.  You posted some 
very good emails out there on the status of your effort but we need 
something more to make this catch on for #5.  In an ideal world we would 
all be able to experiment with different containers (for #6) but we just 
don't have the time which leads again to #7.

To tell you the truth we have big concerns that overshadow the container 
effort right now.  First on that list is multi master replication so we 
can make the directory and all that rests upon it fault tolerant.

That does not mean I am not interested in OSGi or getting this stuff 
working and integrated into the main trunk.  I'm sure we're going to see 
several benefits from using a container again.


John E. Conlon wrote:
> Think it is time to begin the process of moving OSGi into our trunk for 
> the 1.5.0-SNAPSHOT.
> Propose that instead of adding parallel projects that wrap our existing 
> projects in OSGi bundles, that we instead add OSGi metadata to the jars 
> that are created by our existing projects.   This is easily done by 
> adding the org.apache.felix maven-bundle-plugin to our subproject 
> pom.xml files.
> While Enrique and I used wrapping techniques in our initial OSGi 
> parallel project experimentations, working more directly on each of our 
> subprojects offers IMO significant advantages.
> 1. Fewer projects. It's basically a few lines in an existing project 
> versus a new project.
>    + N existing projects versus N x 2 projects via the wrapper approach.
>    + While it is possible to wrap multiple subprojects in uber OSGi 
> bundles, this still will produce N number of additional projects for us 
> to maintain.
> 2.  Direct control of OSGi metadata would offer techniques for improved 
> decoupling between subprojects
>    + Working directly with OSGi  (Subproject) developers will have the 
> tools (via plugin instructions) to begin to focus on offering to users 
> of their jars (bundles) public exported packages as well as hiding 
> implementation in private packages within the module.
> 3.  Better modularity at deploy time.
> What does everyone think?
> cheers,
> John

View raw message