Name: 
Why are you still not using Hudson?
This week Hudson was awarded the Duke’s Choice Award in the Developer Solutions category at JavaOne.
In the space of a couple of years, Hudson has come from nowhere to become the leading contender among Continuous Integration servers. It’s head and shoulders above the other free alternatives, and arguably at least as good as the commercial offerings.
The venerable Cruise Control led the way for many years, but it suffers for having been first. Configuring builds is a lot more work than it needs to be. Continuum improved on this by allowing everything to be controlled via the web interface. Continuum is simple and useful. For a while I used it and I was happy.
Then JetBrains gave away free TeamCity licences with IntelliJ IDEA 6.0 and opened my eyes to a world beyond the fairly basic functionality of Continuum. I was impressed (pre-tested commits are a neat feature), but because you needed licences for every user, I was never able to fully commit to it.
NOTE: JetBrains have since introduced a free professional edition of TeamCity.
Anyway, at some point last year I took a serious look at Hudson. I’d been vaguely aware of it for a little while but never been compelled to try it out.
Hudson is impressive. It is ridiculously easy to install. It has the same ease-of-configuration that makes Continuum so simple, but it combines it with high-end features, such as distributed builds, that are usually only found in commercial offerings like TeamCity and Atlassian’s Bamboo.
Hudson is primarily the work of Sun Microsystem’s Kohsuke Kawaguchi. Kohsuke is a prolific Open Source developer. With Hudson he has designed a system with well thought-out extension points that have enabled an army of plug-in writers to deliver a bewildering array of capabilities.
Out-of-the box Hudson supports CVS and Subversion repositories. Plug-ins extend this list to include Git, Mercurial, Perforce, ClearCase, BitKeeper, StarTeam, Accurev and Visual SourceSafe. Hudson also supports pretty much any type of build script (including Ant, Maven, shell scripts, Windows batch files, Ruby, Groovy and MSBuild).
In addition to e-mail and RSS, Hudson can also notify you of build events via IRC and Jabber as well as via a system tray/dock applet. Of course, all of these were too mundane for Kohsuke, so he built his own glowing orb 
But Hudson is much more than just a Continuous Integration server. It’s a complete build management and tracking solution. As well as publishing Javadocs, archiving build artifacts, and monitoring and graphing JUnit/TestNG results over time, you can also track and plot code coverage (Cobertura, EMMA and Clover are all supported) and coding violations (via FindBugs, Checkstyle and/or PMD). And if all that’s not enough, you can play the Continuous Integration game.
So why are you still not using Hudson?
on May 10th, 2008 at 2:20 pm
It’s interesting that you would sing Hudson’s praises and that I would find this article a matter of days after our QA lead gave up on Hudson. Our primary reason for ditching it is because it simply would not cooperate with dependency management. If A depends on B, we make a breaking change in B that causes changes in A. Hudson (set up for A) wouldn’t recompile B. I’m not convinced that this system is as great as the awards it seems to be winning.
on May 10th, 2008 at 3:18 pm
Brian, I guess that’s a good answer to “why are you not using Hudson?”
Hudson has a lot of features and I have not used all of them. I don’t have dependencies set-up between individual projects so I have not encountered that specific problem.
Out of interest, did you find an alternative that did solve your particular problem?
on May 11th, 2008 at 9:04 am
Hi, we use hudson for more than 20 projects, and dependencies work fine.
on May 11th, 2008 at 2:49 pm
We are using an older in-house system for now. I believe our QA team is still following up to figure out why things weren’t working like we expected.
on May 11th, 2008 at 4:30 pm
Great question. I think people don’t realize how easy it is to setup.
The hard part is writing tests.
on May 12th, 2008 at 3:33 pm
[...] Why are you still not using Hudson? Hudson is a complete build management and tracking solution. As well as publishing Javadocs, archiving build artifacts, and monitoring and graphing JUnit/TestNG results over time, you can also track and plot code coverage. (tags: continuousintegration java) [...]
on May 21st, 2008 at 7:27 pm
Found your post because it had the words “Cobertura” and “plot” in it, while googling for something better than QALab… And well, it convinced me to try out Hudson, which I’d never heard about before.
Like you said, installing Hudson and setting it up to build our project (and even draw those pretty graphs from Cobertura output) was totally a snap! We’ll be just test-driving it for now, but I think we might well end up replacing CC as our main build tool…
So thanks for the introduction!
on May 23rd, 2008 at 10:03 pm
[...] Why are you still not using Hudson? [...]
on May 31st, 2008 at 1:48 am
>>Of course, all of these were too mundane for Kohsuke, so he built his own glowing orb.
Blogger Jamie Matthews built his Gmail Notifier Lamp cube. He has blogged it at http://www.j4mie.org/2008/02/15/how-to-make-a-physical-gmail-notifier/
on June 5th, 2008 at 2:04 am
Well, I am using it and am increasingly frustrated with it. My current frustration is that when our unit tests fail it doesn’t fail the build. Instead, it goes on to run the coverage tests. Strangely, if the coverage tests (cobertura) fail Hudson will fail the build, but if the unit tests fail and cobertura is happy with the coverage, the build gets marked “yellow”. This appears exactly backwards to me.
Michael
on July 17th, 2008 at 4:33 pm
Hi Michael
Could your problem be with poorly configured ant setup? We had a recent problem, in that our cobertura tests caused our build to fail, even though the unit test succeed. But that turned out to be a problem with the way we defined our ant targets in our build.xm file .