[DISCUSS] Proposal to make the Yoko ORB a subproject of Geronimo.

[Rick McGuire <ri...@gmail.com>]

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.

Rick


The members of project yoko have been considering the future of Yoko as 
a project.  There have been several milestones delivered and the project 
is used by other ASF projects.   The project is not as active as other 
ASF projects and it makes sense to move the code from Yoko to other 
projects.  The Yoko team has the following proposal for your consideration.

Proposed Code Donation from Project Yoko to Apache CXF and Apache Geronimo

The Yoko community has been successful in delivering several milestones 
of the ORB implementation while in the Apache Incubator.  These 
milestones are used by other Apache projects (namely Geronimo and 
Harmony) to support their releases.  The WebServices bindings are 
dependent on CXF.  The Yoko community has decided that the Yoko project 
does not have quite the momentum to carry itself as an independent 
project but has sufficient value for other projects for them to consider 
receiving the code and committers for that code-base as sub-projects.  
Since the code under consideration is used by Apache Geronimo, Apache 
CXF and Apache Harmony the movement of the code should continue to allow 
for independent releases so the code can be easily shared with other 
dependent projects.

The proposed division is:

yoko-spec-corba - this is the org.omg interface classes.
rmi-spec - this is the javax.rmi spec implementation
core - This is the actual ORB implementation.
rmi-impl - This is the implementation of the RMIIIOP support.

These modules are also used by Harmony.

In addition to the code we propose that the following committers in 
Apache Yoko be accepted as committers in Apache Geronimo given their 
demonstration of delivering code, creating releases and functioning as a 
community.  Those noted with asterisks are already Geronimo committers.

Continued involvement with the core:

Rick McGuire *
David Jencks *
Alan Cabrera  *
Lars Kuhne
Alexey Petrenko
Darren Middleman

The remainder of the modules in Yoko are part of the webservices support 
and are independent of the underlying ORB implementation.

api -- interface classes used for the web services support.
bindings -- code to implement the CORBA-Web services bindings.
tools -- tools for generation WSDL and IDL for the bindings
maven-plugin -- some maven plugins that can use the tools for generating 
binding-related build artifacts.  None of the maven-plugin code is used 
by the ORB.

There is also a distribution directory with some sample applications.  
One set of samples demonstrates using the core ORB, the other set is for 
WebServices.  We recommend that the distribution directory should move 
to Apache CXF as the webservices examples use the orb samples to bind 
them as web services.  Since Apache Geronimo's only use of CORBA is for 
exporting EJBs, these samples are not particularly valuable for Geronimo.

The Yoko community did not have any committers that expressed an 
interest in continuing work on these bindings.  As such, only the code 
would be moving to apache CXF.

Re: [DISCUSS] Proposal to make the Yoko ORB a subproject of Geronimo.

[Donald Woods <dw...@apache.org>]

I agree and would support adding Yoko as a subproject and adding the 3 
new committers.

-Donald

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...
> 
> --kevan
> 
> 

Re: [DISCUSS] Proposal to make the Yoko ORB a subproject of Geronimo.

[Tim Ellison <t....@gmail.com>]

Alan D. Cabrera wrote:
> On Dec 5, 2007, at 2:22 AM, Rick McGuire wrote:
>> Kevan Miller wrote:
<snip>
>>> 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.

Yep, Corba is a significant part of the Java SE spec too and Harmony has
been taking Yoko drops as part of our implementation.  IMHO it doesn't
make sense for us to fork the code and maintain it independently of
Geronimo.  Alexey (one of the proposed new committers) is on the Harmony
PMC so can help keep things honest.

Regards,
Tim

Re: [DISCUSS] Proposal to make the Yoko ORB a subproject of Geronimo.

["Alan D. Cabrera" <li...@toolazydogs.com>]

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

Re: [DISCUSS] Proposal to make the Yoko ORB a subproject of Geronimo.

[Rick McGuire <ri...@gmail.com>]

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
>
>

Re: [DISCUSS] Proposal to make the Yoko ORB a subproject of Geronimo.

["Alan D. Cabrera" <li...@toolazydogs.com>]

On Dec 4, 2007, at 4:56 AM, 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...

These reflect my sentiments as well.


Regards,
Alan

Re: [DISCUSS] Proposal to make the Yoko ORB a subproject of Geronimo.

[Kevan Miller <ke...@gmail.com>]

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...

--kevan

Re: [DISCUSS] Proposal to make the Yoko ORB a subproject of Geronimo.

[Rick McGuire <ri...@gmail.com>]

I personally think we should go the local build route.  Until the 
subproject's been integrated in Geronimo, it's still bound by the 
incubating release rules.  I suspect getting a 1.0 release actually 
approved and out the door in time for 2.1 given the current state of the 
community is not something we'd want to depend on.  The local build like 
we used for 2.0 is probably the best approach at this date.

Rick

Joe Bohn wrote:
> A related question.
>
> We currently have a dependency in Geronimo 2.1 on Yoko 
> 1.0-incubating-SNAPSHOT.  We need to eliminate that snapshot 
> dependency (and several others) before we can ship Geronimo 2.1.
>
> Assuming that active VOTE passes .... would is the possibility of 
> releasing a 1.0 version of Yoko in time for Geronimo 2.1?
>
> I was just looking at the possibility of creating another local build 
> for the Geronimo release but I think we could have an official release 
> of Yoko in Geronimo if it becomes subproject of Geronimo.  Does that 
> sound feasible or should we create a private build for Geronimo 2.1?
>
> Joe
>
>
> 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.
>>
>> Rick
>>
>>
>> The members of project yoko have been considering the future of Yoko 
>> as a project.  There have been several milestones delivered and the 
>> project is used by other ASF projects.   The project is not as active 
>> as other ASF projects and it makes sense to move the code from Yoko 
>> to other projects.  The Yoko team has the following proposal for your 
>> consideration.
>>
>> Proposed Code Donation from Project Yoko to Apache CXF and Apache 
>> Geronimo
>>
>> The Yoko community has been successful in delivering several 
>> milestones of the ORB implementation while in the Apache Incubator.  
>> These milestones are used by other Apache projects (namely Geronimo 
>> and Harmony) to support their releases.  The WebServices bindings are 
>> dependent on CXF.  The Yoko community has decided that the Yoko 
>> project does not have quite the momentum to carry itself as an 
>> independent project but has sufficient value for other projects for 
>> them to consider receiving the code and committers for that code-base 
>> as sub-projects.  Since the code under consideration is used by 
>> Apache Geronimo, Apache CXF and Apache Harmony the movement of the 
>> code should continue to allow for independent releases so the code 
>> can be easily shared with other dependent projects.
>>
>> The proposed division is:
>>
>> yoko-spec-corba - this is the org.omg interface classes.
>> rmi-spec - this is the javax.rmi spec implementation
>> core - This is the actual ORB implementation.
>> rmi-impl - This is the implementation of the RMIIIOP support.
>>
>> These modules are also used by Harmony.
>>
>> In addition to the code we propose that the following committers in 
>> Apache Yoko be accepted as committers in Apache Geronimo given their 
>> demonstration of delivering code, creating releases and functioning 
>> as a community.  Those noted with asterisks are already Geronimo 
>> committers.
>>
>> Continued involvement with the core:
>>
>> Rick McGuire *
>> David Jencks *
>> Alan Cabrera  *
>> Lars Kuhne
>> Alexey Petrenko
>> Darren Middleman
>>
>> The remainder of the modules in Yoko are part of the webservices 
>> support and are independent of the underlying ORB implementation.
>>
>> api -- interface classes used for the web services support.
>> bindings -- code to implement the CORBA-Web services bindings.
>> tools -- tools for generation WSDL and IDL for the bindings
>> maven-plugin -- some maven plugins that can use the tools for 
>> generating binding-related build artifacts.  None of the maven-plugin 
>> code is used by the ORB.
>>
>> There is also a distribution directory with some sample 
>> applications.  One set of samples demonstrates using the core ORB, 
>> the other set is for WebServices.  We recommend that the distribution 
>> directory should move to Apache CXF as the webservices examples use 
>> the orb samples to bind them as web services.  Since Apache 
>> Geronimo's only use of CORBA is for exporting EJBs, these samples are 
>> not particularly valuable for Geronimo.
>>
>> The Yoko community did not have any committers that expressed an 
>> interest in continuing work on these bindings.  As such, only the 
>> code would be moving to apache CXF.
>>
>

Re: [DISCUSS] Proposal to make the Yoko ORB a subproject of Geronimo.

["Alan D. Cabrera" <li...@toolazydogs.com>]

On Dec 6, 2007, at 8:05 AM, Joe Bohn wrote:

> A related question.
>
> We currently have a dependency in Geronimo 2.1 on Yoko 1.0- 
> incubating-SNAPSHOT.  We need to eliminate that snapshot dependency  
> (and several others) before we can ship Geronimo 2.1.
>
> Assuming that active VOTE passes .... would is the possibility of  
> releasing a 1.0 version of Yoko in time for Geronimo 2.1?
>
> I was just looking at the possibility of creating another local  
> build for the Geronimo release but I think we could have an  
> official release of Yoko in Geronimo if it becomes subproject of  
> Geronimo.  Does that sound feasible or should we create a private  
> build for Geronimo 2.1?

Lars Kuhne has some concerns about releasing v1.0.  Maybe those have  
changed now that Yoko is in a different place.


Regards,
Alan

Re: [DISCUSS] Proposal to make the Yoko ORB a subproject of Geronimo.

[Joe Bohn <jo...@earthlink.net>]

A related question.

We currently have a dependency in Geronimo 2.1 on Yoko 
1.0-incubating-SNAPSHOT.  We need to eliminate that snapshot dependency 
(and several others) before we can ship Geronimo 2.1.

Assuming that active VOTE passes .... would is the possibility of 
releasing a 1.0 version of Yoko in time for Geronimo 2.1?

I was just looking at the possibility of creating another local build 
for the Geronimo release but I think we could have an official release 
of Yoko in Geronimo if it becomes subproject of Geronimo.  Does that 
sound feasible or should we create a private build for Geronimo 2.1?

Joe


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.
> 
> Rick
> 
> 
> The members of project yoko have been considering the future of Yoko as 
> a project.  There have been several milestones delivered and the project 
> is used by other ASF projects.   The project is not as active as other 
> ASF projects and it makes sense to move the code from Yoko to other 
> projects.  The Yoko team has the following proposal for your consideration.
> 
> Proposed Code Donation from Project Yoko to Apache CXF and Apache Geronimo
> 
> The Yoko community has been successful in delivering several milestones 
> of the ORB implementation while in the Apache Incubator.  These 
> milestones are used by other Apache projects (namely Geronimo and 
> Harmony) to support their releases.  The WebServices bindings are 
> dependent on CXF.  The Yoko community has decided that the Yoko project 
> does not have quite the momentum to carry itself as an independent 
> project but has sufficient value for other projects for them to consider 
> receiving the code and committers for that code-base as sub-projects.  
> Since the code under consideration is used by Apache Geronimo, Apache 
> CXF and Apache Harmony the movement of the code should continue to allow 
> for independent releases so the code can be easily shared with other 
> dependent projects.
> 
> The proposed division is:
> 
> yoko-spec-corba - this is the org.omg interface classes.
> rmi-spec - this is the javax.rmi spec implementation
> core - This is the actual ORB implementation.
> rmi-impl - This is the implementation of the RMIIIOP support.
> 
> These modules are also used by Harmony.
> 
> In addition to the code we propose that the following committers in 
> Apache Yoko be accepted as committers in Apache Geronimo given their 
> demonstration of delivering code, creating releases and functioning as a 
> community.  Those noted with asterisks are already Geronimo committers.
> 
> Continued involvement with the core:
> 
> Rick McGuire *
> David Jencks *
> Alan Cabrera  *
> Lars Kuhne
> Alexey Petrenko
> Darren Middleman
> 
> The remainder of the modules in Yoko are part of the webservices support 
> and are independent of the underlying ORB implementation.
> 
> api -- interface classes used for the web services support.
> bindings -- code to implement the CORBA-Web services bindings.
> tools -- tools for generation WSDL and IDL for the bindings
> maven-plugin -- some maven plugins that can use the tools for generating 
> binding-related build artifacts.  None of the maven-plugin code is used 
> by the ORB.
> 
> There is also a distribution directory with some sample applications.  
> One set of samples demonstrates using the core ORB, the other set is for 
> WebServices.  We recommend that the distribution directory should move 
> to Apache CXF as the webservices examples use the orb samples to bind 
> them as web services.  Since Apache Geronimo's only use of CORBA is for 
> exporting EJBs, these samples are not particularly valuable for Geronimo.
> 
> The Yoko community did not have any committers that expressed an 
> interest in continuing work on these bindings.  As such, only the code 
> would be moving to apache CXF.
>