It still looks like Jenkins is outpacing Hudson. To be fair, Jason van Zyl (who is working on Hudson) gave advance warning that we’d see something like this:

We are moving more carefully and probably slower then we might like, but we feel that, in order to aggressively add features in the future, the testing infrastructure, development infrastructure, and core features need to be in place. All this work I’m talking about will likely take a release or two to get in place but once that is done we will be moving at a radically different pace.

Nevertheless, one wonders how much longer this can go on before the momentum becomes irreversible.

With the commercial support of both Oracle and Sonatype behind the development of Hudson, the future looks good for the eponymous continuous integration tool. However, Jenkins continues to evolve as well [etc, etc]…

I’m not so sure about Hudson’s future. Fortunately, there are a number of easily measurable indicators that should allow us to gauge the progress of these two rival projects.

First, we can look at commit counts. Specifically, commit counts should provide a decent leading indicator of the health of each project, given that they generally foretell whether or not the project is likely to address user needs in new releases.

Second, we can look at user mailing list post counts, which generally tell the story of user uptake after all of the hard work has gone into fixing bugs, adding features and cutting new releases. I would consider user mailing list usage to be a lagging indicator.

So after two weeks, what does the commit picture look like? Well, Hudson has seen 40 commits since the split [1], while Jenkins has seen 166 commits. It’s not even close. As a leading indicator, this bodes well for Jenkins’ future.

What about user mailing list activity? Remember that logically this should be a lagging indicator. As such, I expected the Hudson user list to remain more active than the Jenkins user list for quite some time, even if Jenkins ends up overshadowing Hudson over time. Astonishingly, the Hudson user list has seen 55 posts since the split, while the Jenkins user list has seen 563 posts in the same time frame! Have users already decided, en masse, to adopt Jenkins over Hudson? That’s certainly the picture painted by these numbers.

Two weeks is an extremely small track record on which to base any conclusions, and some of these numbers may be distorted by infrastructure issues on the Hudson side, but I think it’s safe to say that Hudson’s future is a little murkier than Alex’s optimism might suggest. The good thing is that we’ll be able to revisit these numbers in 6 months and have a pretty clear idea of where things are headed

[1] All of the counts in this post are as of the time of writing, and begin counting on February 1st, 2011.

UPDATE (4/4/2011): I’ve posted a newer commit graph here.

Further, I had just read a series of articles by Cédric Beust regarding recent improvements to the TestNG threading engine. In short, TestNG allows you to run tests on multiple threads in order to shorten the test suite run time. However, when you start creating tests with dependencies on other tests, TestNG punts and runs all of these groups of dependent tests serially, on a single thread. Cédric wanted to remove this limitation, and approached the enhancement as a topological sort problem, viewing the tests as nodes in a directed acyclic graph.

Most of the startup time in Spring-centric applications involves the initialization of singleton beans. It wasn’t too much of a mental leap to wonder if the same graph/sort approach could be applied to the application startup optimization question — with the Spring beans acting as the nodes in the graph, instead of the tests.

It turns out to be (sort of) possible, and (sort of) worth the time. I’ve posted the details, including the source, here. Feel free to check it out and make suggestions. The Spring framework does contain a very coarse lock that required a pretty horrible hack in order to get any performance gains out of the experiment, but once this is worked out I don’t see why an implementation of this approach couldn’t make it into real applications. Again, see the project page for more details.

On a side note, this is the first time that I’ve used GitHub to host any code, and I have to say that I really like the fact that the README file serves the dual purposes of local project documentation and homepage markup!

It appears there will be a 2.5.7 release within the next couple of months (see slide 14), but it’s probably going to be the first of the commercial-only Spring releases. However, Spring 3.0 is also due within the next couple of months (see slide 5); let’s hope for a fix then. Otherwise, they may have to take JBoss off of the deploy graph on slide 4

It’s exciting to see the steady improvement in JavaScript support. From the HtmlUnit main page:

The unit tests of some well-known JavaScript libraries are included in HtmlUnit’s own unit tests; based on these unit tests, the following libraries are known to work well with HtmlUnit:

• jQuery 1.2.6: Full support (see unit test here )
• MochiKit 1.4.1: Full support (see unit tests here )
• GWT 1.5.3: Full support (see unit test here )
• Sarissa 0.9.9.3: Full support (see unit test here )
• Prototype 1.6.0: Very good support (see unit test here )
• Ext JS 2.2: Very good support (see unit test here )
• Dojo 1.0.2: Good support (see unit test here )
• YUI 2.3.0: Good support (see unit test here )

In an attempt to find a balance between their open source roots and their commercial obligations, SpringSource made a mistake. They’ve now admitted it, and they’ve acted upon that knowledge. Kudos to them.

Back to work.

Customers who are using SpringSource Enterprise, available under a subscription, will receive maintenance releases for three years from the general availability of a major new version. These customers receive ongoing, rapid patches as well as regular maintenance releases to address bugs, security vulnerabilities and usability issues, making SpringSource Enterprise the best option for production systems.

After a new major version of Spring is released, community maintenance updates will be issued for three months to address initial stability issues. Subsequent maintenance releases will be available to SpringSource Enterprise customers. Bug fixes will be folded into the open source development trunk and will be made available in the next major community release of the software.

Now, there are only two ways I can read this:

1. After the initial three-month window following a major release, bug fixes will not be available to non-paying customers until the next major release.
2. After the initial three-month window following a major release, bug fixes will be available to non-paying customers only via public source control — not via real, numbered releases.

If we take the Spring 2.5.x series of releases as an example, we have the following time line:

Spring 2.5.0: 2007-11-19
Spring 2.5.1: 2008-01-09
Spring 2.5.2: 2008-02-29
Spring 2.5.3: 2008-04-06
Spring 2.5.4: 2008-04-28
Spring 2.5.5: 2008-06-23

Applying the three-month rule to these releases, we can see that the community around this open source project would only have access to Spring 2.5.0, 2.5.1 and 2.5.2 (if we’re generous and round up).

I’m not sure whether or not the community would have access via public source control to the bugfixes included in the subsequent releases prior to the next major release, but as far as I can tell the best-case scenario is that we would have to build the subsequent releases ourselves, rather than just download the JARs directly.

Additionally, this policy takes effect immediately. If you’re not paying SpringSource, you may not get access to the upcoming 2.5.6 release…

Somebody tell me I’m misreading this.

UPDATE: Here.

If you’ve used Eclipse before, you know that it provides feedback as you type, alerting you if your package name is not valid as is. For example, if you type “net.gredler.app.”, Eclipse will helpfully throw up the following error:

Invalid package name. A package name cannot start or end with a dot.

Well, I eventually got to “net.gredler.app.con”, and received the following error message:

Invalid package name. con is an invalid name on this platform.

Weird, no? It turns out that there are some limitations on directory names in Windows: you can’t have directories named “con”, “prn”, “aux” or “nul”, among others.

Apparently these were reserved words in DOS back in the day, and this restriction has propagated to the latest versions of Windows in the name of backward compatibility.

So if you’re coding in Linux or Mac OS X and want to ensure that your Java web application isn’t deployable on Windows, adding a package named “con” ought to do the trick (assuming your servlet container explodes WARs)

Have I missed any?