CORBA on Kenai
By kcavanaugh on Apr 30, 2009
The GlassFish CORBA project has been hosted in a variety of places in the past 10 years. It started from the original IBM/Sun joint development work on RMI-IIOP, with additions from the ORB team at Sun including the POA, PortableInterceptors, a streaming GIOP transport, and many others. This was originally hosted internally at Sun using the (now mostly forgotten) TeamWare source code management system. TeamWare had many faults, such as a lack of tools and a requirement for NFS access to the repository, that made it increasingly unusable, especially as more of Sun's software became open source. But TeamWare had one big advantage at the time over most other available version control systems: it was fully distributed, and supported unlimited cloning of repositories.
The next step for the CORBA project was to be open sourced as part of GlassFish. Because of this, I created the GlassFish-CORBA project on java.net, and migrated the ORB source into subversion. Given that java.net only supports CVS and subversion, that was clearly the better choice, but subversion, like CVS, does NOT support multiple repositories. My working style involves a lot of parallel development of independent features across multiple release, and I find this much easier to manage with multiple repositories (often arranged in a parent-child hierarchy of clones) than with multiple branches in a single repository.
Work has been going on at Sun for a number of years to transition to a newer version control system than TeamWare. The OpenSolaris team did an evaluation and chose Mercurial as their version control system. Other projects at Sun have followed, including the OpenJDK project. My own experience with Mercurial is that it is everything I want in a replacement for TeamWare. Mercurial is a fully distributed version control system that runs well across the internet, and has a reasonable selection of tools (and more being developed all the time).
Of course, having a good version control system is only part of the solution: you must also have a well-run site that hosts the version control system. Mercurial comes with a built-int simple solution (hg serve) which is fine for serving a single repository temporarily (such as between desktop and notebook systems), but is not suitable for more complex scenarios. The scripts that come with Mercurial are better, but lack a lot of necessary features. And of course the repository server needs to be highly available with lots of bandwidth on the internet.
Kenai has recently been announced at Sun, as a new "forge" to develop software. As such, Kenai is more than just a version control repository: Kenai provides all of the basic tools needed for managing a software project, such as a Wiki, issue tracking with either BugZilla or Jira, multiple source code repositories per project, project management, and mailing lists. Jira is particularly nice, and probably the best bug tracking system I've used.
I currently have two public projects on Kenai:
The GlassFish CORBA (gf-corba-v3-mirror), which contains almost 3700 files.
The GlassFish MBean Annotation Library (gmbal), which contains just under 900 files.
Both of these are delivering code into GlassFish version 3. Gmbal started as a library in the GlassFish CORBA project, then I moved it out to a separate project as interest developed in Gmbal from other projects.
One of the most useful features on Kenai is the ability to have multiple repositories for a project. I use this in several ways:
To handle parallel releases (like GlassFish versions 2 and 3).
- To provide integration areas for projects not ready for the main development stream (these are temporary).
- To provide a staging model for managing software releases.
Our staging model works as follows:
- All developers that are members of the gf-corba-v3-mirror project can push to the staging repository.
- Only release engineering (RE) can push to the master repository (this is represented in Kenai by the content developer role, which I otherwise do not use).
Automated tests are run against the staging repository using Hudson.
- When the tests pass, and the developers have reached a suitable milestone, RE can run a small Hudson job that propagets the latest changesets from the staging repository to the master, updates the version, and releases OSGi bundles to the Maven repository.
I think the staging model is easier to work with in a distributed version control system like Mercurial than in a centralized system. In particular, you can use roles to enforce access permissions as needed for the staging model, since each repository has its own access control.
I've been using Kenai for a year or so now, and it has worked very well, with very few early alpha or beta issues. I have had a few issues (like understanding the initially strange interactions with Sun's unified access control system and Kenai logins), but the Kenai team has been extremely responsive at getting issues resolved. Uptime and responsiveness for the site have both been outstanding, and are both much better than I have experienced with java.net.
Of course, Kenai is still a young project, and does not have all the features that I would like to see:
- More integration with Maven and Hudson would be quite useful. Currently deploying to Maven is by far the slowest part of the build cycle for my projects.
Support for static web pages is required before I can fully migrate away from java.net. GlassFish CORBA is actually currently split in two: the online docs are visible at GlassFish-CORBA (on java.net), while all of the source code in on gf-corba-v3-mirror (on Kenai.com).
- Eventually we will need some help in the form of tools and APIs to aid in migrating existing projects to Kenai.
The Kenai team is very responsive in listening to all the developer requests for features, and doing a reasonable job of prioritizing their development resources. Perhaps most importantly, the availability and responsiveness of the site has been excellent throughout the time I've been using it.