Cheesy Title

Archive for May, 2008

Generating FlexUnit Test Reports with Flex Mojos

Thursday, May 29th, 2008

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:

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

Working with SVNKit

Tuesday, May 27th, 2008

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.