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.
