I was watching rather apprehensively the split in Hudson development (Hudson/Jenkins fork). My team was using Hudson CI for over a year now, and we came to rely on it as a key component of our Software Development Ecosystem, with extensive customization and integration; we really like the product and the idea that we would have to replace it was enough to give me jitters (I even blogged about it here)
I view this as a positive development, even as some in the field disagree
"Oracle today announced that it has submitted a proposal to the Eclipse Foundation to create a Hudson project in Eclipse and contribute the Hudson core code to that project."
"Under the new proposal, Oracle will be the project lead with Sonatype, Tasktop, and VMware as initial contributors.Other companies are also listed as project supporters."
Looks like my celebration was a bit premature, and there appear to be a lot of acrimonious feeling in the developers community. They voice their frustrations here, in the post by Mik Kersten
At the same time, Kohsuke Kawaguchi uploaded a presentation on SlideShare with his own narrative on the split, and his perspective on the future developments.
I guess we have no choice but wait until the dust settles.
It did not take long for Oracle to tighten its grip on the jewels which it fond itself in possession of with Sun Microsystems acquisition. The examples include Java spat resulting in Google's Android lawsuit and changes that lead to Apache Foundation withdrawal from the Java Community Process. Here's the recent one - expropriation of Hudson Continuous Integration Server
Not surprisingly, the Hudson developers bailed out, leaving Oracle with the only asset that it really owns - the name "Hudson". The fork of the code is fait accompli: the new Jenkins site is up and running, and the project is being considered for Apache Foundation umbrella - where it logically belongs.
Oracle maintains that this ousting of the project's founder Kohsuke Kawaguchi was in the best interests of the project because now they'll be able to bring in "real structure" and make the project "corporate friendly". Needless to say that neither are the top priorities of the open source community, Oracle has pushed the wrong key - again.
Subversion is one of the finest version control systems out there (Ok, GIT afficionados might disagree :)), it can run on any OS out there - Linux, FreeBSD, MacOS, Windows..
Well, almost. For a number of reasons, I am running my sandbox SVN environment on Windows (Windows 2003).
Here is a stack trace of an error logged into Hudson; the build failed on check-out step:
Checking out https://XYZ.test.agilitator.com:8443/svn/Sandbox/hudson ERROR: Failed to check out https://XYZ.test.agilitator.com:8443/svn/Sandbox/hudson org.tmatesoft.svn.core.SVNException:
is not canonicalized; there is a problem with the client.
svn: REPORT of '/svn/Sandbox/!svn/vcc/default': 400 Bad Request (https://XYZ.test.agilitator.com:8443)
This somewhat cryptic error was thrown once IP addresses to SVN repository were replaced with URL. It took us quite awhile to discover the culprit: uppercase URL.
For me, this "case sensitivity" underscores Linux heritage of SVN, the Windows port was an afterthought..