Hudson Speaks! Plugin

Plugin Information

Plugin ID speaks
Latest Release 0.1.1
Latest Release Date Dec 02, 2009
Plugin Central Plugin Central 3.2
Sources Subversion
Support Eclipse Hudson Forum
Issue Tracking Eclipse Bugzilla
Hudson Core (latest) 3.3.3

This plugin gives Hudson a voice using FreeTTS.


This plugin requires that:

  • Hudson's server machine has a working sound card and speaker.
  • Hudson's server machine's speaker is not in a remote server room where there's no one around to hear it. Preferably in audible range of the development team Hudson is working for.

IMPORANT: Please use the 'Test speech' button in the global preferences before using Hudson Speaks! as a build notifier. If the test does not complete, or no sound is heard, you should not use Hudson Speaks! as a build notifier, and check your audio hardware.

During testing it has been found that if a linux machine does not have a correctly configured audio device, the FreeTTS library call can hang trying to speak. This will cause your build executor to hang too, and result in Hudson failing.


Hudson Speaks! is configured using a Jelly XML Script (just like a lot of the internals of Hudson itself).

The context that the Jelly script runs in is pre-configured with these variables:

  • ${build} - the current build
  • ${duration} - the duration of the build formatted for speech.
Example script (the default):
    <j:when test="${build.result!='SUCCESS' || build.project.lastBuild.result!='SUCCESS'}">
        Your attention please. Project ${}, build number ${build.number}: ${build.result} in ${duration}.
        <j:if test="${build.result!='SUCCESS'}"> Get fixing those bugs team!</j:if>
    <j:otherwise><!-- Say nothing --></j:otherwise>

This means an announcement will only be made if the current build, or the previous build was not a success. In other words the project was broken by this build, the project is still broken, or the project was fixed by this build.

The script can be specified at the global level, and also overridden at the project level.


This Plugin should work out-of-the-box on Windows, but often under Linux the sound device is not accessible.

If Hudson refuses to talk on Linux, but the 'Test speech' says success, check that the sound device (often /dev/dsp) is writable by your Hudson user:

$ ls -l /dev/dsp
crw-rw-rw- 1 root root 14, 3 Oct 22 16:35 /dev/dsp

If not, get someone with sufficient system privileges to change it for you:

$ chmod +rw /dev/dsp


An alternative to this is to use the CCTray app that comes with CruiseControl.NET and have it monitor your Hudson server. You can set this up on a shared machine or on individual developer machines. To have CCTray monitor Hudson, set it up to monitor a custom URL that looks like http://hudsonserver:hudsonport/hudsonpath/cc.xml

Basically, appending cc.xml to almost any Hudson URL (project, view, etc.) will return an XML document that CCTray can parse. You can then use CCTray to play .wav files, speak, or even control X10 devices.

CCTray is available at


  • Version 0.1.1 (2nd December 2009)
    • Repackaged with Hudson 1.324 (no functional changes)
  • Version 0.1 (29th November 2009)
    • Initial release


plugin-notifier plugin-notifier Delete
plugin-misc plugin-misc Delete
Enter labels to add to this page:
Wait Image 
Looking for a label? Just start typing.
  1. Dec 24, 2010

    Dieter De Meyer says:

    Hello, I find your plugin interesting but would it be possible to let this plug...


    I find your plugin interesting but would it be possible to let this plugin send the speech to a list of other machines on the same network?
    A lot the time, the Hudson server is not in the same room as the developers.

    Just a suggestion.


  2. Jun 24, 2011

    Andrew Wall says:

    Hi - thanks for your work on this. Our team loves it and have a great time maki...

    Hi - thanks for your work on this. Our team loves it and have a great time making "hudson" say all kinds of crazy things.

    Just a comment on the example - it appears that for every build, the values




    refer to the same object. I guess the point at which this plugin gets included in the build process - build.project.lastBuild has already been updated. I found that build.project.builds[1] will refer to the build before the one that just got completed.