John,
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.
Alex
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
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
