Sorry - The link below was a little further back in the thread: Here's the one where the OSGi discussion starts, although the previous messages on the thread are a good backdrop.
http://mail-archives.apache.org/mod_mbox/james-server-dev/200604.mbox/[EMAIL PROTECTED] --- Ole Ersoy <[EMAIL PROTECTED]> wrote: > 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/[EMAIL PROTECTED] > > 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 > > > > > > > > > ____________________________________________________________________________________ > Expecting? Get great news right away with email > Auto-Check. > Try the Yahoo! Mail Beta. > http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html > > ____________________________________________________________________________________ Get your own web address. Have a HUGE year through Yahoo! Small Business. http://smallbusiness.yahoo.com/domains/?p=BESTDEAL
