Cheesy Title

July 3rd, 2008

Hudson Twitter Plugin 0.2 Released

I released a new version of the Twitter plugin for Hudson today. You can see the details at

This is the third plugin I’ve written in whole or part and I continue to be extremely impressed with Hudson’s extensibility. I’ve got some other ideas, but I think I’m going to put those on hold and instead concentrate on building out a library for unit testing plugins as I seem to be running into the same issues over and over again.

June 4th, 2008

JRuby Cookbook available for Pre-Order

In case you didn’t notice the sidebar links, Henry Liu and I are wrapping up a JRuby Cookbook for O’Reilly and it’s up on Amazon for pre-order

June 4th, 2008

Using Xvnc within Hudson to run FlexUnit tests

Like most people unit testing Flex applications with FlexUnit in a Continuous Integration environment, I’ve based our setup on Peter Martin’s blog post from January 2007. In it, he describes one of the core challenges of this type of configuration: the fact that the CI server is likely headless. Martin’s solution is to use Xvfb. And this works fine.

But Hudson can do better because someone (Kohsuke, I assume) wrote a plugin for Xvnc. Simply install the plugin and check the checkbox in the job configuration screen:

Hudson will then automatically start up a Xvnc session and set the DISPLAY environment variable to the appropriate value and then shut down the session when the build is complete. One advantage this has over the Xvfb method is that if you have multiple Flex projects building simultaneously, each build has its own X session. While this has yet to be an issue for our projects, it seems like a good idea. The architecture of FlexUnit actually makes simultaneous builds a bit tricky. In another post, I’ll cover how Hudson can solve this problem too.

A word of warning:
Before using this plugin, you obviously have to have Xvnc installed. What’s less obvious (although sensible) is that you must also set a password. You do this by running:
$ vncpassword
This has to be done as the same user Hudson runs as.

June 1st, 2008

FlexUnit reports in Hudson

As a follow-up to my post about using the FlexUnit results produced by the flex-mojos Maven plugin to produce a unit test report, I wanted to point out that this same technique can be used within the Hudson continuous integration server.

Here’s what the config looks like:

(Note that we’re also using Hudson’s JavaDoc support to publish the produced ASDoc).

This gives you all the nice Hudson unit testing support like graphs of tests per build:

UPDATE – With the Flex Mojos 1.0 release, the output directory for FlexUnit tests has changed. It’s now surefire-reports, so the Test report XMLs value should be **/target/surefire-reports/*.xml.

May 29th, 2008

Generating FlexUnit Test Reports with Flex Mojos

The flex-mojos project supports unit testing of Flex code, but it doesn’t use Maven’s default surefire plugin for running tests. As a result, you need to make a slight tweak to your pom.xml file:


Here’s some sample output:

UPDATE – With the Flex Mojos 1.0 release, the output directory for FlexUnit tests has changed. It’s now surefire-reports, so you can simply include the surefire-report plugin in your pom.xml file without any configuration:

May 27th, 2008

Working with SVNKit

We’re doing a big project at work that involves splitting up a large codebase into lots of little projects. The general methodology is:

  1. Create a new directory in Subversion.
  2. Copy some stuff from the main codebase into the new directory.
  3. Compile/fix
  4. Package
  5. Delete files from the codebase and replace with the packaged jar.

One of the problems that’s come up is that the codebase is a moving target; people not involved in the extraction are making change all the time. I use Fisheye notifications to let me know when a change has been made to the codebase, but that requires me to remember to set up the notification.

So I decided to write a Maven plugin that would iterate through all the files in the extraction target directory and see if there are newer versions in the codebase. This means getting the info per file up until the point it was copied and then checking the URL the file was copied from to see if there are newer revisions.

I started doing this by passing calling the Subversion command line client with the –xml option and then using some XPaths to extract the necessary bits. There were two problems with this approach:

  • svn and svadmin had to be on the path
  • the code wasn’t readable

The former wasn’t that big a deal locally, but when I committed the unit test that used svnadmin, the tests failed on the CI server because svnadmin wasn’t on the path. The second was obvious while I was writing the code, but figured I’d deal with it later.

Rather than have svnadmin added to the path, I took a look at svnkit and found the API to be pretty clean. Things I really like (in no particular order):

  • Very OO.
  • Defaults to using the default Subversion authentication store.
  • Good use of File objects – cut way down on calls to file.getAbsolutePath()
  • Really helpful for unit testing – e.g. SVNURL objects can be compared against one another

Things I didn’t like:

  • Wasn’t super-intuitive what methods were in which Client class – why is doInfo() in SVNWCClient and not in, say, SVNLogClient
  • Methods could be overloaded more with defaults that matched the command-line
  • SVNWCClient.doAdd() only accepts one File at a time
  • Latest version isn’t in Maven Central

But the biggest issue is speed, at least it seems to be. It sure seems slower when running my unit tests in Eclipse, but Hudson doesn’t show a big difference. Build #13 is when I introduced a minimal about of svnkit just to get svnadmin functionality working. Build #20 is all svnkit and is actually a few seconds faster. I’ll have to look more at this going forward.