Due to some maintenance issues, this service has been switched in read-only mode, you can find more information about the why

and how to migrate your plugin documentation in this blogpost

Skip to end of metadata
Go to start of metadata

Plugin Information

View RAD Builder on the plugin site for more information.

This plugin allows Jenkins to invoke IBM Rational Application Developer as a build step.

Tutorial regarding the use of this plugin

For a complete tutorial describing how to use this plugin, refer to the Enhance continuous integration using Rational Application Developer and the Hudson build server article on developerWorks.

Introduction to Rational build utility

The nice guide to the Rational Build Utility details, on developerWorks, how to use the headless feature of Rational Application Developer.

About this plugin

This plugin is aimed at using the headless capabilities of IBM Rational Application Developer (RAD) 7.0/7.5, which is Ant-based, to build J2EE applications designed with RAD.

This plugin currently supports:

  • RAD 7.0 (version 1.x successfully tested with RAD and RAD – should work with other 7.0.0.x versions)
  • RAD 7.5 (version 1.x successfully tested with RAD 7.5.3, 7.5.4, 7.5.5,, and – should work with other 7.5.x versions)
  • RAD build utility (BU) 7.5 (version 1.x successfully tested with BU 7.5.3, 7.5.4, 7.5.5,, and – should work with other 7.5.x versions)
  • RAD build utility (BU) 8.0 (version 1.1.4 successfully tested with BU 8.0.2 – should work with other 8.0.x version)

BU is the fully headless version of RAD.

User guide

This plugin works as the built-in Ant builder:

  1. The first thing to do is to define RAD/BU installations in Hudson's configuration panel:
  2. Once done, corresponding build steps can be added to the project:

About the WORKSPACE environment variable

RAD uses an environment variable called workspace to define the RAD workspace to use. It means that there's a "competition" (no matter the case) between this variable and the one defined by Hudson (which refers to the project's workspace). As a consequence, don't use the WORKSPACE variable within this build step as it doesn't refer to what's expected.

Additional documentation

  • To get more information on the headless capabilities of RAD 7.0, please refer to the RAD 7.0 Infocenter
  • To get more information on the headless capabilities of RAD 7.5, please refer to the RAD 7.5 Infocenter
  • To get more information on BU 7.5, please refer to the RAD 7.5 Infocenter.
  • To get more information on BU 8.0, please refer to the RAD 8.0 Infocenter too.

Version history

Version 2.0 (source code not yet opened)

  • Support of WebSphere Message Broker Toolkit

Version 1.1.4 (03/04/2011)

  • Fixed a bug which was preventing to display RAD installations actually used by build steps (the first item in the installations list was always selected)

Version 1.1.3 (02/20/2011)

  • Implemented JENKINS-8652: Build logs are now annotated so that the logs for Ant targets can be accessed faster
  • Fixed JENKINS-8545: RAD Builder refused to work if the RAD installation path on a slave node was different than the path on the master node

Version 1.1.2 (03/27/2010)

  • Improved handling of the WORKSPACE/workspace environment variable: Now, the plugin sets RAD's workspace using workspace (lower case letters) whether it is running on Windows or Linux

Version 1.1.1 (01/24/2010)

  • Bug fix: The "Create PROJECT_WORKSPACE variable" option now works fine (previously, this new variable was created at the end of the build step rather than at the beginning)

Version 1.1 (12/04/2009)

  • The "Delete RAD workspace" option is now checked by default
  • Bug fix for the WORKSPACE environment variable on Windows: RAD/BU expects it to be an absolute path, not a relative one
  • Experimental (not yet tested): New "Create PROJECT_WORKSPACE variable" option to provide a replacement for the WORKSPACE environment variable

Version 1.0.1 (10/12/2009)

  • Bug fix for the WORKSPACE/workspace environment variable on Linux
  • Switch to the right groupId (org.jvnet.hudson.plugins rather than hudson.plugins)

Version 1.0 (10/11/2009)

If you use version a RAD or a BU installation on Linux, you need to edit, respectively, bin/runAnt.sh or eclipse/bin/runAnt.sh to change the workspace environment variable to WORSKPACE. Otherwise, RAD/BU may fail complaining that no valid workspace has been found (depending on the permissions of the user used to run RAD/BU). This has been fixed in 1.0.1.

  • Initial release


  1. Unknown User (stephen.callaghan@shinetech.com)

    I'm confused how the "workspace" works here. I had thought that I was checking out the whole RAD workspace, that being the case, why does the plugin create a new workspace as a subdirectory to my hudson one or set one up elsewhere? I have build scripts that all work fine, linkage to 7.5 has been setup correctly, but I cant workout how to execute the scripts in the right project.

    Apologies as I realise this is probably something really simple! Any help much appreciated.

    1. Unknown User (rseguy)

      There are two kinds of workspaces there: The Hudson job one and the RAD one.
      By default, the plugin will create from scratch a new RAD workspace to ensure it is clean and good for use before using it (this RAD workspace is placed within the Hudson job workspace). It is then the responsibility of the RAD build file to set up the RAD workspace as expected, generally using EPF files. It makes sense to have such a behavior to ensure developers comply with rules formalized in these EPF files (+ it saves you from uploading the big .metadata folder).
      It's anyway still possible to not use this automatically generated RAD workspace (which is, finally, just a simple folder): Just uncheck the various "Remove ..." options and make the "RAD workspace" field point to your existing RAD workspace (this path is then relative to the workspace of the Hudson job).