geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick McGuire <rick...@gmail.com>
Subject Re: [DISCUSS] Proposal to make the Yoko ORB a subproject of Geronimo.
Date Wed, 05 Dec 2007 10:22:25 GMT
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.

Rick


>
> --kevan
>
>


Mime
View raw message