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 Sun, 11 Feb 2007 16:05:15 GMT
John E. Conlon wrote:
> Hi Alex,
> Thanks for the comments.  See inline for responses.

Truly thanks for your effort to push OSGi along. I really want to go 
this route but I want all our bases covered.

Having read your response and Emmanuel's, I think I would like to wait 
until we have a *non*-snapshot release of the OSGi plugin in the Maven 
repository to use before tackling this in May or better yet June.  I 
don't want the build to depend on SNAPSHOT plug-ins because I would not 
allow a production release so long as we did.

We can re-evaluate this and prep the team by then so we can all 
participate in this OSGi aim together.  It would be nice to have you 
involved with the guts of ApacheDS as well as being on the periphery 
with the OSGi effort and likewise I'd like to see the rest of the team 
more involved with the OSGi effort.  I'd like to also see if you can get 
OSGi to give us certain things like JMX for free so we can better 
control and instrument the server.

I want to know what our benefits are going to be and who is going to be 
involved with making sure we get those benefits.  Also what's the deal 
with Spring-OSGi? Is there some advantage to be gained there?  Do we get 
the best of both worlds?

Let's get your documentation into the Apache confluence under the 1.5 
confluence's developer guide area and more people on this team looking 
at it and commenting on it.

This sound good?


> Alex Karasulu wrote:
>> Doing this means committing to OSGi and I'm not going to be too 
>> comfortable with doing this until I see:
> We can look at this two ways.  From one perspective we would not be 
> committing 'fully' to OSGi, as the decorated metadata would not affect 
> the behavior of the jars as they operate today.
> One of the big issues for the OSGi community today is to convince 
> library providers to add a few lines of metadata to their jars artifacts 
> so they could also be used in OSGi projects.   So from this perspective 
> I guess I am trying to convince us to 'at least' to make our jars OSGi 
> friendly.
> Let me respond to your to your other points from the second perspective :-)
>> (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,
> Your right we need "in container" integration testing once we fully 
> commit to OSGi.
> The Spring-OSGi effort is offering just such a testing environment.  I 
> am told knopflerfish also has one but have not looked into it. I have 
> used the Spring-OSGi testing on several occasions including testing some 
> of the OSGi ApacheDS bundling efforts in the sandbox.   Within the 
> Spring-OSGi facilities exist for testing Equinox (Eclipse's standalone 
> runtime), Knopflerfish and of course Felix.
> Caveat is that Spring-OSGi is still in early development and the API's 
> are changing.  Nevertheless the testing side has been pretty stable and 
> allowed the kind of testing we needed.
> For a simple example see my sandbox for 
> osgi-services/logging-service-integration-test. This tests the 
> neighboring logging-service project which creates a bundle which offers  
> slf4j/commons/LogService api adapters on the NLOG4 bindings.   
> Implementation and testing was eventually noticed Ceki, who asked me to 
> do something similar for slf4j.  This is now committed in the 
> 1.3.0-SNAPSHOT of the slf4j project.
> There is also a simple mina integration testing project in my sandbox. 
> It uses a chat server as a server within the OSGi container.
>> (2) good test coverage, testing the integrated system of ApacheDS 
>> services running inside an OSGi container (you need #1 for this)
> Right.  The real challenge I am faced with is to provide a Spring-OSGi 
> integration test for the Configuration Admin service implementation that 
> I committed a two weeks ago.  This will require a full stack of ApacheDS 
> bundles running within the various OSGi containers.  This will also 
> expose an LDAP service that will require test cases.
> Must confess I am still not fully up to speed on the new schema 
> functionality to fix my broken apache-core-osgi project which I will 
> need for such an integration test. (Next week maybe?)
>> (3) solid documentation in confluence for this OSGi based architecture 
>> for ApacheDS
> Top down documentation without buyin by developers most often times is 
> ignored as it is either too abstract or if not, grows stale fast.  
> Especially if it is done by a single person that doesn't fully 
> understand the foundations of what he is documenting. (that would be me.)
> What I posted at 
> is still  valid as a top down viewpoint for what we are doing with OSGi 
> and ApacheDS today and what I am proposing with this email.
> (PS - Will move it to confluence if it is not there already.)
> In that document written 10 months ago I said:
> "Structurual Componetization can also be called '*/Package Depenency 
> Management/*'.   Structurual Componentization is the initial focus of 
> the OSGi work effort.  It will consist of annotating ApacheDS software 
> artifacts with OSGi specific metadata."
> This architectural document really needs more fleshing out than I  have 
> given it to date, but to do this I am going to need help, and the help I 
> need must come from the bottom up.  To continue to document the reality 
> based top down I need the bottom up 'trenches' view of the ApacheDS 
> effort.  We need to start working on the documentation at the package 
> and subproject basis in order to begin thinking about - '*/Package 
> Depenency Management/*'.
> Three step loop here:
> 1. Document packages
> 2. Annotate jars ( plugin produced metadata  documents dependencies.)
> 3. Analyze dependencies (Refactor to improve coupling?)
> As it is now the OSGi effort at ApacheDS is not sustainable as I am 
> doing too much outside of the group.   With my proposal I am trying to 
> get our community enthused enough to assist with this bottom effort.
>> (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),
> The  only plugin we need at first would be org.apache.felix 
> maven-bundle-plugin and it is available from one of our current default 
> repos:
> <url></url>
>> (5) greater team awareness of this OSGi based architecture,
> Right - thats the purpose of my proposal.
>> (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.
> Agree to #7 - ditto comment for #5.
> cheers,
> John

View raw message