directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John E. Conlon" <jcon...@verticon.com>
Subject Re: [OSGi] Implementing OSGi for 1.5
Date Sat, 10 Feb 2007 17:09:02 GMT
Hi Alex,

Thanks for the comments.  See inline for responses.

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 http://docs.safehaus.org/display/APACHEDS/OSGi+and+ApacheDS
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>http://people.apache.org/repo/m2-snapshot-repository</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





Mime
View raw message