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
