Hudson Helper: Hudson On Your iPhone

I'm a big fan of Continuous Integration and automated builds. So much so that today I released Hudson Helper, a native iPhone and iPod Touch application for monitoring your Hudson continuous integration engine.

Hudson Helper has a simple interface that gives you what you need to know first. Offline data caching helps to minimize network bandwidth and makes it work when the network is unavailable. Includes job status, health and build trends.

Build status display adapts to your project to report on build health including JUnit test results, Clover coverage, findbugs and any other Hudson build report plug-ins your project is running.

To get started all you need to do is point Hudson Helper at the URL of your build server. You can get Hudson Helper by searching for 'Hudson Helper' in the app store, or click here to get it with iTunes.

Eclipse 3.5 (Galileo) on Java 7

Some time ago I blogged about running Eclipse (Ganymede) on SoyLatte. Since then there has been little improvement in the state of Java on the Mac. Apple has released a Java 6 for Mac, but it's a 64-bit only VM which crashes regularly when running Eclipse. Having heard about recent improvements in performance for 64-bit VMs using pointer compression (PDF paper), I decided to have another look at launching Eclipse with an OpenJDK-based VM such as JDK7. After a few false starts I managed to get it working. Here's what I did:

First, to get JDK7 on my machine. I followed these instructions to build JDK 7 from source. The instructions didn't work perfectly for me -- but they were pretty good. Basically followed everything verbatim with the exception that I had to install MacPorts and use it to get wget.

With a 32-bit JDK7 on my machine, now to use it to start Eclipse. I downloaded the latest I-build of 32-bit Eclipse 3.5 from here (Look for '3.5 Stream Integration Builds').

Using a combination of jconsole and guesswork I came up with this shell script to start Eclipse:

JDKPATH=/Users/dgreen/Documents/packages/jdk7-32bit-2009-05-08
DEBUG_OPTS=
# DEBUG_OPTS=-Xdebug -Xrunjdwp:transport=dt_socket,address=1044,server=y,suspend=y
MEM_OPTS=-Xms1024m\ -Xmx1536m\ -XX:MaxPermSize=256m
ECLIPSE_LOC=/Users/dgreen/Downloads/eclipse
WORKSPACE=/Users/dgreen/Documents/workspace

$JDKPATH/bin/java $DEBUG_OPTS \
-cp $ECLIPSE_LOC/plugins/org.eclipse.equinox.launcher_1.0.200.v20090429-1630.jar \
-XstartOnFirstThread $MEM_OPTS \
-Dorg.eclipse.swt.internal.carbon.smallFonts \
-Djava.library.path=$ECLIPSE_LOC/Eclipse.app/Contents/MacOS/lib \
-Dswt.library.path=$ECLIPSE_LOC/Eclipse.app/Contents/MacOS/lib \
org.eclipse.equinox.launcher.Main \
-os macosx -ws cocoa -arch x86 \
-showsplash -launcher $ECLIPSE_LOC/Eclipse.app/Contents/MacOS/eclipse \
-name Eclipse \
--launcher.library $ECLIPSE_LOC/plugins/org.eclipse.equinox.launcher.cocoa.macosx_1.0.0.v20090429-1630  \
-startup $ECLIPSE_LOC/plugins/org.eclipse.equinox.launcher_1.0.200.v20090429-1630.jar \
-data $WORKSPACE \
-keyring /Users/dgreen/.eclipse_keyring -consoleLog -showlocation \
-vm $JDKPATH

Note that all of the above should appear on one line: your browser may split it into multiple lines.

After starting Eclipse as above I saw the following stack trace on startup:

java.lang.UnsatisfiedLinkError: no swt-pi-cocoa-3547 or swt-pi-cocoa in swt.library.path, java.library.path or the jar file
 at org.eclipse.swt.internal.Library.loadLibrary(Library.java:248)
 at org.eclipse.swt.internal.Library.loadLibrary(Library.java:159)
       ... snip ...

To solve the problem I extracted all of the *.jnilib files from org.eclipse.equinox.launcher_*.jar and put them in a lib folder. I then renamed all of those *.jnilib files in the lib folder so that they had *.dylib file extensions. I ended up with a file structure as follows:

david-greens-macbook-pro:MacOS dgreen$ pwd
/Users/dgreen/Downloads/eclipse/Eclipse.app/Contents/MacOS    <--- where I put the files
david-greens-macbook-pro:MacOS dgreen$ ls -l *.sh lib
-rwxr-xr-x@ 1 dgreen  staff  1100  8 May 15:47 eclipse.sh    <--- the startup script

lib:        <---- the lib folder for shared libraries
total 2296
-rw-r--r--  1 dgreen  staff   37104  8 May 14:20 libswt-awt-cocoa-3547.dylib
-rw-r--r--  1 dgreen  staff  287116  8 May 14:20 libswt-cocoa-3547.dylib
-rw-r--r--  1 dgreen  staff  539240  8 May 14:20 libswt-pi-cocoa-3547.dylib
-rw-r--r--  1 dgreen  staff  300428  8 May 14:20 libswt-xulrunner-cocoa-3547.dylib

Trying the shell script again, Eclipse started up and ran beautifully! Once again I'm running Eclipse with a newer-than-Apple-will-give-me VM, this time JDK 7!! My next step is to compile a 64-bit JDK7 and see if it works too... I have high hopes.

• Updated 2009-05-15 see this issue (bug 276564) for the underlying cause of failure
• Updated 2010-01-19 see Eclipse 3.6 on OpenJDK on Mac OS X for an update

How Babel Saved My Bacon

Recently I blogged about the pain of moving to ICU4J, lamenting the fact that using NLS instead of ResourceBundle would require me to change the keys in my resource bundles. After much consideration and the advice of knowledgeable people, I decided that moving to NLS was the way to go. After changing resource bundle keys across the board, I expected that translations to other languages would need their corresponding keys changed as well. Not so. Apparently Babel can magically handle such refactorings, with the help of a mystery user named 'Babel Syncup'. I wonder what else it can do.

The Eclipse Babel project is truly impressive. Kudos to the Babel team for thinking ahead.

Peter Friese on Advanced WikiText

Peter Friese has upped the stakes in his latest article on Advanced WikiText. Friese tackles tough topics, such as how to optimize team collaboration with multiple source files and integrating with a DocBook toolchain. Great article, a must-read for those who are authoring documentation.