geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <l...@toolazydogs.com>
Subject Re: [DISCUSS] Proposal to make the Yoko ORB a subproject of Geronimo.
Date Wed, 05 Dec 2007 20:26:09 GMT

On Dec 5, 2007, at 2:22 AM, Rick McGuire wrote:

> Kevan Miller wrote:
>>
>> On Dec 3, 2007, at 1:45 PM, Rick McGuire wrote:
>>
>>> Below is a proposal that Matt Hogstrom, one of the mentors of the  
>>> Yoko project, has put forward for moving on with the Yoko  
>>> project.  In a nutshell, the Yoko community has basically decided  
>>> there is not a lot of continuing interesting in moving this  
>>> project forward.  This decision does have a major impact on  
>>> Geronimo, as Geronimo uses the Yoko ORB was a key element to  
>>> allow Geronimo 1.2 to support both the 1.4 and 1.5 JVMs, and also  
>>> was a necessary element for achieving j2ee5 certification.  The  
>>> Yoko ORB gives Geronimo cross JVM portability which was not  
>>> available before.  At the current time, there's probably no  
>>> suitable replacement that has all of the advantages that the Yoko  
>>> ORB provides.
>>> In a nutshell, Matt's proposal is for the core ORB elements of  
>>> the Yoko project become a subproject of the Geronimo project.   
>>> These are the pieces of Yoko that Geronimo has a dependency  
>>> upon.  These are essentially the org.omg.* clases, the  
>>> javax.rmi.* classes, plus the implementation classes backing  
>>> those spec interfaces.  Along with the subproject, there are 6  
>>> committers who have expressed interest in continuing to work on  
>>> the core ORB code.  3 of the interested commiters are already  
>>> Geronimo committers.  Matt's proposal would grant the remaining 3  
>>> Geronimo committer status as well.
>>>
>>> There's one important caveat in assuming owership of this  
>>> package.  The core ORB is also used by the Harmony project to add  
>>> CORBA and RMI support to the Harmony JVM.  Included with assuming  
>>> ownership of the package would be a commitment to keep the core  
>>> ORB a "standalone" component.  This means not adding direct  
>>> dependencies on Geronimo and keeping dependencies on other  
>>> packages to a minimum.
>>> This code is fairly stable now, and has already passed  
>>> certification on multiple JVM instances, so I don't expect there  
>>> will be a lot of overhead in supporting this.  The bulk of the  
>>> recent work to get this to pass certification have been done by  
>>> Geronimo committers, so Geronimo is probably the most appropriate  
>>> new home for this code.
>>> Anyway, this needs to have some discussion and be put to a vote.   
>>> Below is the proposal that Matt posted to the Yoko dev mailing  
>>> list about this move.  The Yoko community seems very much in  
>>> agreement that project does not have sufficient momentum to  
>>> graduate from the incubator.
>>
>> Thanks for the summary, Rick.
>>
>> I'm certainly interested in seeing support for Yoko move forward.  
>> This seems like a positive move. It would have my support.
>>
>> After a brief review of the Yoko dev list archives and based on  
>> Matt's, and Alan's recommendations, I would support adding Lars,  
>> Alexey, and Darren to as Geronimo committers.
>>
>> Keeping Yoko as a standalone component is an easy decision, IMO.  
>> Hard to see it any other way...
>
> Actually, I have a whole laundry list of things that could be done  
> to Yoko to make it work better in the Geronimo environment that  
> could mess it's ability to function as a standalone server if not  
> done "correctly".  For example, it would be nice if Yoko could hook  
> into the Geronimo thread pooling APIs.  It's easier to ensure  
> things like this are done in the correct fashion if the constraint  
> of needing to remain standalone is stated right up front.

You make a good point.  We should be very explicit about the  
requirement that Yoko be standalone.


Regards,
Alan




Mime
View raw message