Hudson and Jenkins: Two Months Later

April 4, 2011 at 8:12 pm (Hudson, Java, Jenkins, Oracle)

For some reason I’m finding the Hudson / Jenkins split to be particularly interesting, so I’ve updated the chart from my last post on the subject to span two months, rather than the initial two weeks:

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.

3 Comments

Hudson and Jenkins: Two Weeks Later

February 15, 2011 at 10:50 pm (Hudson, Java, Jenkins, Oracle)

Most Java developers have probably heard about the recent Hudson/Jenkins split. InfoQ’s most recent article on the topic, by Alex Blewitt, ends on an upbeat note:

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.

12 Comments

Optimizing Spring Application Startup Time

January 20, 2010 at 11:17 am (Java, Optimization, Spring)

The application I’m currently working on is built around Spring. A couple of weeks ago, as I waited for it to start up for the 27th time that day, I began wondering if there was any way to get it to start faster. Coincidentally, our whole development team had just received upgraded laptops, so the fact that numbers are stagnating in the “Megahertz” department (but not in the “CPU cores” department) had been recently emphasized.

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!

2 Comments

JBoss 5 + Spring 2.5.6 = BOOM!

January 10, 2009 at 9:47 pm (Java, Spring)

If you tell Spring 2.5.6 to scan the classpath for application context XML files and you’re deploying to JBoss 5, you may run into this bug; something to do with JBoss’ new Virtual File System (VFS) and its non-standard URLs. It looks like this issue was caught in time to be fixed for 2.5.6, but I guess the SpringSource guys didn’t have time to test it before releasing — the fix doesn’t really work.

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 ;-)

3 Comments

HtmlUnit 2.4 Released

December 31, 2008 at 12:12 pm (HtmlUnit, Java)

HtmlUnit 2.4 has been released. See the changelog for more information about all of the improvements made since September, when version 2.3 was released. The TSS announcement is probably a good place to comment or ask questions about this release.

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 )

3 Comments

SpringSource Reworks Maintenance Policy

October 7, 2008 at 2:56 pm (Java, Spring)

A couple of weeks ago SpringSource modified their maintenance policy. The change was a significant move in that it stripped non-paying users of certain perks (rights?), to the point of triggering arguments regarding what, exactly, constitutes an “open source” project.

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.

2 Comments

SpringSource Killing the Golden Goose?

September 19, 2008 at 11:03 am (Java, Spring)

As per this post on TSS, SpringSource have announced a new maintenance policy:

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.

7 Comments

Maven + log4j 1.2.15 = BOOM!

September 12, 2008 at 1:05 pm (Java, Maven)

Don’t try to use log4j 1.2.15 with Maven 2 — they didn’t mark their optional dependencies optional, forcing you to download and locally install a bunch of JavaMail, JMX and JMS JARs. More info here. Bug report here.

Comments Off

From the Annals of Leaky Abstractions

August 19, 2008 at 6:33 am (Java)

Last week I created a new Java package named “net.gredler.app.converter” during a bit of refactoring. I know, I know. Pretty impressive stuff. But there’s more.

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) ;-)

3 Comments

Maven Enhancements to Keep an Eye On

August 5, 2008 at 1:17 pm (Java, Maven)

MNG-3397: More concise POM syntax (more info here).
MNG-3379: Concurrent artifact resolution (more info here).
MNG-2315: Easy mass transitive dependency exclusions.
MNG-1977: Global transitive dependency exclusions.

Have I missed any?

Comments Off

« Older entries

Follow

Get every new post delivered to your Inbox.