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?
Thanks,
Alex
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
begin:vcard
fn:Alex Karasulu
n:Karasulu;Alex
org:Apache Software Foundation;Apache Directory
adr:;;1005 N. Marsh Wind Way;Ponte Vedra ;FL;32082;USA
email;internet:[EMAIL PROTECTED]
title:Member, V.P.
tel;work:(904) 791-2766
tel;fax:(904) 808-4789
tel;home:(904) 808-4789
tel;cell:(904) 315-4901
note;quoted-printable:AIM: alexokarasulu=0D=0A=
MSN: [EMAIL PROTECTED]
Yahoo!: alexkarasulu=0D=0A=
IRC: aok=0D=0A=
PGP ID: 1024D/4E1370F8 BBCC E8D8 8756 2D51 C3D4 014A 3662 F96F 4E13 70F8=0D=0A=
x-mozilla-html:FALSE
url:http://people.apache.org/~akarasulu
version:2.1
end:vcard
