Apache XML-RPC 3.1.2

Glad to announce the new version of Apache XML-RPC, available from the Apache Mirrors. As usual with this project, the bad olds are that the developers (including myself, of course) are almost gone. The project would be ready for archiving, unless (and that is the good news) it were for the contributors: This release was completely driven by users of Apache XML-RPC. Not a single bug fix or patch was created by the committers: Everything came from contributors through Jira or the mailing list. You can view it for yourself by looking on the changes. (And that list doesn't even include XMLRPC-163.) Imagine that with a closed source product.

NonApache.Org

It is now more than 5 years that I enjoy my status as an Apache committer. I still believe it is something to enjoy, although I am getting older and less active. I have learned to live with the realities that must be accepted: This applies, in particular, to the legal straitjacket, but also to the considerations that a community applies. A community? There are plenty of them, each of which very different: For example, the Webservices project tends to take things rather easy, whereas Commons, or Incubator can be quite formal: Javadoc jar file with or without META-INF/NOTICE.TXT? Good enough reason for hours and hours of discussion. Then, legal-discuss can be quite interesting. And the infrastructure mailing list is always a good place for listening what's going on. Sadly, it never paid for me to listen to jobs@apache.org. :-)

That said, there always are cases when I am not sure whether it's worth the hazzle. Running a project (effectively) on your own within the ASF basically means that you have the actual project work plus ASF related burdens. For example, pushing a Apache projects release can be quite some work: I honestly marvel at people like John Casey who has the patience to deliver 10 release candidates in a row. (I feel exhausted after three or four release candidates.) Compare that to the times of JaxMe 1 when I published a new release after almost any commit. Of course, that won't be possible for projects like Maven, or Axis. But there's something to the "Release early, release often" mantra.

I always thought that this uneasiness with the ASF procedures and the responsibility to the community would be my personal problem, (Let's face it: I'm much more of a Maverick than a team player.) until I read Robert Burell Donkin express similar feelings as the reason for starting RAT at Google Code. But what made me think even more was the recent discussion on a proposed Commons Incubator project: Obviously, there are a lot of projects, which are small and expect to remain small, would like to enter the ASF, but don't manage to overcome hurdles like the rule of at least three committers. Are they doing themselves something good?

The FSF is hosting a server called nongnu.org: It contains a lot of (mostly smaller) projects which manage themselves, which most likely feel attracted by or even close to the FSF and it's ideals. These projects don't have the FSF's holy endorsement (sorry, Incubator members, but that's what "endorse" reads to me sometimes), but they are able to work, to publish releases, to attract a community, almost everything an Apache project does.

I'd like to ask you to think whether it wouldn't it be a good idea to have something similar in the grey area of the ASF. For example, Apache Labs could almost immediately move - and finally start publishing releases. The sandbox projects - what could be a better place for living? I have no suggestions for the organizational details, but I think it's worth considering.

Git takes the lead

So far, I have been reluctant to use a DVCS. We have got Subversion and it does an excellent job, at least for me. Ok, the idea of local commits while travelling in the train is compelling, but we might as well have inexpensive UMTS flat rates in the future. Maintaining a local branch over a long time is not what I usually do.

But that's not the overall point, if you are curious to try something new (which I still am, at least from time to time). The killer argument against DVCS has been, IMO, that there isn't the DVCS: We've got Git, Bazaar, Mercurial, to name just the most important ones, not to mention Arch, Monotone, or Darcs. I'd be ready to learn using either, but definitely two or even three. And, until now, I never had the impression that learning one of them would be sufficient. For example, SourceForge does support no less than three different DVCS (as well as grandpa CVS and SVN).

That has changed: The ASF has now a read-only Git repository. Ok, currently it seems to be a one man effort by Jukka Zitting (while writing this, it just came to my mind that I owed him a Kudo on Ohloh), but the interest is obvious, as projects are already requesting to be added. Gnome has recently decided to move to Git completely. If you look into Bug 257706 on the Eclipse bug tracker, then you can't fail to notice that it sounds like Eclipse will have it's first Git repositories soon. (Also note the Git BoF.)

Similar news from Bzr or Hg are missing. Ok, Max Kanat-Alexander is pressing Bugzilla to Bzr (he deserved yet another Kudo, btw), Widelands has moved at least its web site to Launchpad, but the list of projects using Git (including Linux Kernel, Perl, Rails, Fedora, or X.org) tends to become more and more impressive.

Nough said, I'll give it a try. My main reservation will be the quality of JGit and EGit (in fact, these will be the most likely candidates for reasons to withdraw), but I should keep in mind that I refused to use Subversion because of the Subclipse quality as late as 2004. Let's see what the future brings.

When dog food isn't good enough

Recently a proposal came up on the Apache infrastructure list (Sorry, AFAIK, the list isn't archived, thus no pointers from here.) to install Nexus Professional on one of the Apache servers as a repository server. The idea was, in particular, to use Nexus' staging facilities for pushing Apache software releases.

The proposal was posted by Brian Fox, with support by Jason van Zyl. As you can see from my links, both are employed by Sonatype, the company producing Nexus. (Jason is founder and CTO). Obviously, the ASF won't be a bad reference for them. The proposal seems to be rapidly acceptet, almost without objection. (There was some discussion, but mostly about technical details or Maven at all.) As a result, you can view the installed Nexus live today, which is what I did.

In all honesty, I'm going to like it. Having had my share of release management and the related trouble, this is going to help: Pushing some 30 or 40 files to people.apache.org (the number seems big, but you have to consider various signatures, like .md5 and/or .sha1 files as well as GPG signatures, aka .asc files) via SSH to a common place and later distributing it manually to various places is error-prone. But that is like it is: Placement in the common place (typically a users public_html directory) allows the review and vote by fellow developers. Once the release is accepted, the files are being moved to the final target locations. Nexus can help with that and the UI is, of course, very neat.

But that is not the reason for todays entry. What strikes me as rather odd is the fact, how easy a commercial product can make its way into the Apache server park. This is not the first such product: Apache is hosting a Jira server for issue tracking as well as a Confluence Wiki. I observed the discussions when these have been introduced. Jira is basically the successor to the Apache Bugzilla (at least more and more Apache projects leave Bugzilla in favour of Jira) just as well as Confluence is quickly replacing the Apache MoinMoin wiki. In both cases the question was raised, whether an open source product wouldn't be preferrable. Ideally, whether there couldn't be an Apache project to use: "Eat your own dog food" has some tradition within the ASF. The Apache web servers are frequently relatively stable development versions. In both cases there have been no such projects, and the open source alternatives had their share of problems. So I understood the decision.

Which is what I don't do in the case of Nexus as an Apache repository server. There is Archiva, an Apache project, which could do the job. Ok, it doesn't have the bells and whistles, but it does its job. I can tell, because I am using it in my daily work. It is a mature project in active development, obviously also sponsored by commercial companies. Ok, it can't support staging right now, but that wouldn't be overly difficult (Brett Porter has offered to add it, should the ASF require) and within a reasonable time frame. Should be enough at least to consider it as decent dog food.

Alas, noone seemed to be interested in the Nexus discussion. So its Nexus. I can live with it. Understanding is a different matter.

Announce: Apache JaxMas

I'm glad to announce that the world has got yet another (tiny!) open source project, Apache JaxMas. JaxMas is basically a very, very incomplete JAXR implementation.

Why another JAXR implementation? The world has already got plenty of them, for example Apache Scout. My job is mainly about CentraSite, my employers implementation (there's more to it than a simple JAXR implementation, of course). But they all share a common problem: It is basically impossible to use them for unit testing and non-trivial, to use them within integration tests.

The problem is that they all require a running server. And, what's more, it is difficult to start from a predefined set. That's where JaxMas comes into play. JaxMas is running on HSQLDB. The embedded mode of HSQLDB is obviously ideal for unit tests. JaxMas is based on the assumption of an initial schema, that is created by the unit test. The schema is basically a set of SQL commands, but a macro processor allows to create taxononmies and other registry objects relatively easily.

Btw, you might ask me why I didn't choose Apache Derby as the engine. Well, I did initially, but DERBY-338 was blocking me. This issue prevents that two foreign key references exist between the same tables with different ON DELETE clauses. However, I need that feature for deleting even complex registry objects with a simple DELETE statement.

JaxMas?

I am currently preparing a proposal for the Apache Labs. It will be something like an absolute minimal registry for writing JAXR based unit tests, running on Apache Derby. The idea is, that with existing registries (in my case CentraSite) you'll rarely be writing unit tests, because the overhead is so high, that nothing below integration tests makes sense.

Like any child, this one needs a name. With names, however, I am as inventive as the former federal german phone company. (The companies current successor is inventive, in particular with new ways to bill you for things that have been free in the past.) Usually, a projects name would be discussed on the corresponding mailing list.

In this case, however, it is more than likely, that I'll be the only user. So I though to ask here: As far as I know, this blog has at least two users and thats more than one, isn't it? So far my only idea was JaxMas, in honour of my former child JaxMe and due to the fact, that I had the idea on christmas. Better suggestions more than welcome!

Poor Mans GForge

I call myself an extremely experienced person, when it comes to software installation, configuration and stuff like that. Having installed server software like Apache httpd, Bugzilla, Perl, Sendmail, MySQL, innd, snmpd, radiusd, to name a few, on Linux and mainstream Unixes (Solaris, AIX, HP/UX) as well as exotic server operating systems like SGI, ConvexOS, Dec, or Windows, there's a rare chance that an installation may surprise me. The most notable example used to be Hylafax, which really wasn't easy to handle in 1996, or around that. (I wonder what it's like today. The project lives, so things might have changed.)

However, there's another example, which can easily driving me crazy: It's GForge, a collaboration server for developers, that basically enables management of a lot of projects via a comfortable web interface. If you have it installed, that is.

It's not, that I am unable to do it. I have running GForge installations. But my first installation required no less than three days of work, until everything was complete and the fun didn't shrink with the second or third such installation. It's simply that I am wondering whether it's worth the effort. In particular, because I find myself missing Bugzilla anyways, when working with the integrated issue tracker.

So when I recently had to setup a new development server, I decided to try something different: If I am installing Bugzilla (which I would end to do anyways), then I have my preferred issue tracker and a comfortable, multitenant user management tool ready. Why not simply attach Subversion, WebDAV (as a Maven repository) to the Bugzilla database?

The result of my attempt can be found at Bugzilla's own Bugzilla in Bug 392482. (Of course, it wasn't an immediate result. There have been a few evolutionary steps.) It consists of two parts: mod_authn_bugzilla is an authentication module for the Apache httpd. Basically, it's simply mod_authn_dbd with some minor changes (setting of environment variables). The Apache module authenticates users against the Bugzilla database. Like its ancestor, it's database agnostic, so you can use it regardless of the type of the Bugzilla database.

The second part enables management of user ID's with Bugzilla. By default, Bugzilla uses email addresses instead of classical user ID's. Which is of course fine within Bugzilla. However, you wouldn't want to use me@foo.com as part of a subversion URL.

I am quite happy with the system, as it is now. I am using standard components, which come with the Linux distro with almost no configuration changes. For example, my Subversion repositories are where CentOS wants them, and not on GForge's preferred location. The webdav directories are below /var/www, as they should be. Ok, I cannot create new projects via the web interface, but project administration is a rare task: User management is what costs the most time and is typically presumed urgent, so that's what matters.

If you are interested in the details, please contact me.