directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <ole_er...@yahoo.com>
Subject Re: [OSGi] Implementing OSGi for 1.5
Date Sat, 10 Feb 2007 16:09:01 GMT
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.

http://mail-archives.apache.org/mod_mbox/james-server-dev/200604.mbox/%3c4162765.1144418383864.JavaMail.root@81-174-50-40.vps.virtuo.it%3e

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 <akarasulu@apache.org> 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:akarasulu@apache.org
> 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: aok123@bellsouth.net=0D=0A=
> 	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
> 
> 



 
____________________________________________________________________________________
Expecting? Get great news right away with email Auto-Check. 
Try the Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html 

Mime
View raw message