Hey Guys,
It looks like James (Apache Mail Server) has done a
lot of research on XBean and OSGi already.
It sounds like they are favoring OSGi over XBean due
in part to it being standardized through JCP. It
also
sounds like there is an XBean facade for OSGi.
Here's a link to the James thread, starting where
the
discussion gets goooood.
Incidentally - Since they seems to be doing a lot of
work around this already, I think it would make
sense
to combine our efforts with respect to Alex's list
below.
Cheers,
- Ole
--- Alex Karasulu <[EMAIL PROTECTED]> wrote:
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
