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.

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.

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.

<reporting>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-surefire-report-plugin</artifactId>
      <configuration>
        <reportsDirectory>${project.build.directory}/test-reports</reportsDirectory>
      </configuration>
  </plugin>
  </plugins>
</reporting>

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:

<reporting>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-surefire-report-plugin</artifactId>
  </plugin>
  </plugins>
</reporting>

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.