Introduction

Integrating the right tools to get the job done is a longstanding dream of many software developers. When you're able to work in a seamless environment that bridges optimal work environments, you can leverage a powerful union to get the help you need to do the job right. Making the environment work together effectively is critical; before you get started working with the steps outlined in this article, it is important that your organization meets a few key prerequisites, outlined under the required knowledge and tools section.

Required knowledge and tools

To follow the steps in this article, you need to have some knowledge working with the IBM® Rational® Application Developer and to be used to creating Apache Ant (Another Neat Tool) build files.

You'll also need to have the following tools:

• Rational Application Developer build utility 7.5.5
• Ant-Contrib 0.6
• Hudson 1.312 and its Rational Application Developer Builder Plug-in 1.1.2 (their installation is covered in the second part of this article)

See the Resources section to get them.

Back to top

Creating a build file for use with the Rational Application Developer build utility

The Rational Application Developer for WebSphere® Software build utility, hereafter simply referred as the build utility, is an additional component of Rational Application Developer for building J2EE applications in a headless way. "Headless way" means that the build utility can be used on machines with no display, with such machines being generally dedicated, in continuous integration environments, to build applications. As such, the build utility is a perfect tool to help automate the applications builds, when working in a continuous integration environment.

The build utility is command-line driven and uses Ant build files to describe the operations that are to be performed. It comes with a complete set of Ant tasks to build Rational Application Developer applications, like importing projects into a workspace, building a workspace, exporting an application as a WAR or as an EAR file, etc. Take a look at the corresponding section in Rational Application Developer's infocenter to get a complete overview of the build utility features.

As the build utility uses Ant as its foundation, it also benefits from all the standard Ant tasks. Furthermore, it is easy to extend its features by adding new sets of Ant tasks. In this article, we'll use Ant-Contrib (see Resources) to take advantage of new behaviors such as if/then structures, loops, etc.

The application that we'll use to illustrate this article is the EJB 3.0 Online Library one which is available from Rational Application Developer product's infocenter. You can get this from the Rational Application Developer tool by going to Help > Help Contents > Samples > Application samples > EJB 3.0 Online Library > EJB 3.0 Online Library complete implementation and by clicking the Import sample item. This will create three projects in the Rational Application Developer workspace you're currently using:

• EJB3Library is an EJB project containing the EJBs for the application.
• EJB3LibraryWeb is the Web application which makes use of the previously mentioned EJBs and exposes them to the user through a Web UI.
• EJB3LibraryEAR is the EAR project used to package the EJBs and the Web module in a single enterprise application.

This article doesn't cover the installation of the build utility. To get the complete steps to assist you in doing this, please refer to the corresponding section of Rational Application Developer's infocenter. In the following steps, we'll assume that we are building our continuous integration on Microsoft® Windows®, that we are running build utility 7.5.5, and that it is installed in C:\CIEnv\BuildUtility.

We also won't cover the installation of Ant-Contrib (we'll use Ant-Contrib 0.6). Refer to Ant-Contrib's documentation (see Resources) for that. We'll assume that it is installed in C:\CIEnv\ant-contrib-0.6-bin.

Note that the build utility and Hudson, that we'll see in the second part of this article, run on both Microsoft Windows and Linux®, so don't hesitate to pick your preferred platform.

The build file we're going to write to build this application is fairly simple and consists in the following operations:

1. First, it sets up the Rational Application Developer workspace to be used.
2. Next, it imports the projects to build into this new workspace.
3. After, it builds the workspace.
4. Finally, it exports the built application as a single EAR file.

In the following steps, we'll try to make the build file as generic as possible, so that it can easily be reused for other projects. For that, we'll use Ant properties as much as possible, for example to externalize the name of the Rational Application Developer projects to be taken into account by the build file.

Starting the build file

Starting writing the build file is easy. We simply need to create a new file named build.xml, to define the root project tag and to use Ant's taskdef instruction so that the build utility knows where the Ant-Contrib's jar is located:

<project name="rad-builder" default="build-all" basedir=".">

  <!-- Ant-Contrib (if, foreach, etc.) -->
  <taskdef resource="net/sf/antcontrib/antcontrib.properties">
    <classpath>
      <pathelement location="C:/CIEnv/ant-contrib-0.6-bin/lib/ant-contrib-0.6.jar"/>
    </classpath>
  </taskdef>

  <!-- All additional content will be added here -->

</project>
    

Setting up the Rational Application Developer workspace

When building an application with the build utility, creating and setting up the workspace is the first step. It enables the application to build complies with predefined and shared standards. For example, by controlling the workspace setup, it is possible to ensure that the developers have built the application against a specific Java version, or have correctly encoded their source code files, etc.

Since this does not take a lot of time to do, it is recommended that you create and set up a new workspace each time a build takes place. By doing this, you'll be sure that no modifications have been brought out of control and that the standard is applied by all.

Creating a workspace consists in two steps:

1. First, a new folder has to be created on the filesystem.
2. Then, you must set the workspace environment variable so that it points to this newly created folder, before running the build utility.

This has to be done outside of the build file, possibly using a batch file, which looks like as follows on Windows:

set workspace=C:\CIEnv\workspace
C:\CIEnv\BuildUtility\eclipse\bin\runAnt.bat
    

This batch file, that you can name myRunAnt.bat, will expect a build.xml file to be located into the folder from which it is run. If your build file is not named build.xml or is located in another location, then you'll need to use the -buildfile option.

To properly handle the workspace environment variable, we'll add the following code to the build file:

<propery environment="env"/>
<property name="workspace" value="${env.workspace}"/>

Something important to mention here is that Ant properties are case-sensitive: env.workspace is for example not the same as env.WORKSPACE. As a consequence, it is mandatory to ensure that the workspace environment variable has been set using only lower case letters, otherwise env.workspace won't be set and running the build file will fail.

Setting up the workspace is done using the workspacePreferenceFile task. This task sets the workspace preferences based on a file specified using the preferenceFileName attribute. Two different formats can be used for this file:

• The first one is the standard Java properties file, made up of name-value pairs. This is the simplest format to use, but it allows controlling a limited set of settings: The compiler version, some few additional compilation settings and the runtime environments. It doesn't allow, for example, you to control the encoding of the source code. You can get a sample of such a file in Rational Application Developer's infocenter.
• The second one is the standard Eclipse preferences file (.epf extension). This file allows controlling each of the Rational Application Developer preferences. It is harder to manually update, but it can be fully generated from Rational Application Developer. This is the format we'll use in this article since, most of the time, only the runtime environments may have to be manually edited, if ever they were not installed at the same location on all the computers that are intended to build the application.

To use this format, it's necessary to set the useEclipsePrefs attribute of the workspacePreferenceFile task to true (for some older versions of the product, this attribute doesn't exist and it is necessary to use a property named useEclipsePrefs to emulate this feature – refer to your corresponding Rational Application Developer infocenter). If it is set to false or not set, then the build utility expects the format to be the standard properties file one. In our case, we won't directly set the attribute value into the build file: It will be set outside, so that it is not necessary to edit the build file to switch from a properties file to an epf one, by introducing an Ant property named rad.preferences.useeclipseprefs.

<target name="setup-workspace"
  description="Sets the preferences for the current workspace">

  <!-- Some debug information -->
  <echo level="verbose" message="rad.preferences.filename=${rad.preferences.filename}"/>

  <!-- Set the workspace preferences -->
  <workspacePreferenceFile
    PreferenceFileName="${rad.preferences.filename}"
    useEclipsePrefs="${rad.preferences.useeclipseprefs}"
    overwrite="true"/>
  <echo level="verbose" message="workspacePreferenceFile done"/>
</target>

Here you can see that we use a property named rad.preferences.filename to specify the preferences file to use. This is one of the properties we'll use to make this build file as generic as possible.

To generate the Eclipse preferences file, the simplest way is to create a new workspace using Rational Application Developer, to define the settings in Windows > Preferences and then to export them as an epf file by going to

File > Export > General > Preferences. Contrary to the other files detailed in this article, the Download section of this article doesn't provide a sample epf file since it is coupled to the development environment used to generate it.

Note that the build utility also offers other tasks to set up the workspace, for example to set (and get) an individual property, using workspacePreferenceSet (and, respectively, workspacePreferenceGet). It can be used to tweak specific workspace preferences for some particular projects.

Also, note that the workspace used by the build utility is a standard Rational Application Developer one; once created by the build utility, it can be opened with Rational Application Developer to troubleshoot issues, for example in case of compilation errors that were not appearing on developers' workstations. This is useful when writing the build file, to help ensure that it is fully functional.

Importing the Rational Application Developer projects into the workspace

The second step when building an application is of course to import the Rational Application Developer projects into the newly created workspace. The build utility comes with one main task for that: projectImport. We'll use it to import the projects one by one, and we'll use Ant Contrib's foreach task to iterate over a comma-separated list describing all the projects that have to be imported. We could also have used the projectSetImport task, but it requires an extra file to describe the projects to handle.

<target name="import-projects"
  depends="setup-workspace"
  description="Imports a set of projects into the current workspace">

  <!-- Some debug information -->
  <echo level="verbose" message="basedir=${basedir}"/>
  <echo level="verbose" message="projects.name=${projects.name}"/>

  <!-- Import the projects -->
  <foreach
    list="${projects.name}"
    target="import-project"
    param="project.name"/>
</target>

<target name="import-project">
  <!-- Some debug information -->
  <echo level="verbose" message="project.name=${project.name}"/>
  <echo level="verbose" message="workspace=${workspace}"/>
  
  <projectImport
    projectName="${project.name}"
    projectLocation="${workspace}/${project.name}"/>
  <echo level="verbose" message="projectImport ${project.name} done"/>
</target>

Here you can notice that Ant-Contrib's foreach delegates its processing to the import-project target: the foreach task creates and sets, for each comma-separated value in the projects.name property, a new property called project.name, which is the one actually used by the projectImport task.

You may have also noticed that we've defined a dependency between this new target and the setup-workspace one by using the depends attribute (depends="setup-workspace"): This is to help ensure that we don't try to import the projects into a non-correctly set up workspace. We'll use this dependency mechanism for each of the targets we'll define, ensuring that previous ones have been called before next ones are run.

One other important point in this code is the value of the projectLocation attribute of the projectImport task: It is defined as ${workspace}/${project.name}, which means that it expects the project folder to be located within the newly created workspace. That is, the projects have to be copied here before the import is actually done. We do so, so that everything remains in just one place (to ease sharing, for example). To perform this copy, we use the following target, which requires a new copy.from.path property to indicate where the projects have to be copied from:

<target name="copy-projects"
  description="Copies the content of a folder to the current workspace">

  <!-- Some debug information -->
  <echo level="verbose" message="copy.from.path=${copy.from.path}"/>
  <echo level="verbose" message="workspace=${workspace}"/>

  <copy
    todir="${workspace}"
    includeEmptyDirs="true">
    <fileset dir="${copy.from.path}"/>
  </copy>
  <echo level="verbose" message="copy done"/>
</target>

Of course, it means that the import-projects target has a new dependency to this one, and its depends attribute must be updated accordingly:

<target name="copy-projects"
<target name="import-projects"
  depends="setup-workspace,copy-projects"
...
    

Compiling the application

The next step when building an application is to actually compile it. The build utility fits in here, offering two main tasks for that:

• projectBuild is aimed at compiling one project at a time (specified using the projectName attribute).
• workspaceBuild is aimed at compiling the whole workspace: This is the task we'll use since, normally, only required projects have been imported into the workspace and, as such, we don't expect some problematic projects to break the build. This also saves a few lines in our build file compared to using a combination of projectBuild and Ant-Contrib's foreach (simpler is better).

<target name="build-workspace"
  depends="import-projects"
  description="Builds the current workspace">

  <!-- Fully build the workspace -->
  <workspaceBuild
    BuildType="Full"/>
  <echo level="verbose" message="workspaceBuild done"/>
</target>
    

It's worth mentioning that the workspaceBuild task displays useful messages regarding errors that occur during the workspace build. You may also use another task, workspaceGetErrors, to display at a selected place (for example at the end of the build) a selection of these messages (you can for example chose to log only error and warning messages, excluding informational ones).

Exporting the application as an EAR file

Now that the workspace has been compiled, the final step is to export it into the required format. The build utility comes with the following tasks for that, you just have to pick the one(s) you need:

• appClientExport exports an application client project as a JAR file.
• earExport will export an EAR file. It will automatically build the required WAR (for Web applications) and JAR files (for EJBs or utility projects).
• warExport will simply export a Web application. If this Web application depends on some utility projects, these projects will be exported accordingly.

As the sample application we use consists in an enterprise application, we'll use the earExport task to create the EAR file from the previously compiled projects:

<target name="export-ear"
  depends="build-workspace"
  description="Exports the EAR defined by the ear.project.name/ear.filename properties">

  <!-- Some debug information -->
  <echo level="verbose" message="ear.filename=${ear.filename}"/>
  <echo level="verbose" message="ear.project.name=${ear.project.name}"/>

  <!-- Export the EAR project as an EAR file -->
  <earExport
    EARProjectName="${ear.project.name}"
    EARExportFile="${ear.filename}"
    ExportSource="true"
    IncludeProjectMetaFiles="true"
    Overwrite="true"/>
  <echo level="verbose" message="earExport ${ear.filename} done"/>
</target>

You can see here that we introduce two new properties. The first one, ear.project.name, is used to indicate the name of the project which is meant to be exported as an EAR file. The second one, ear.filename, is used to specify the name of this EAR file.

Another important point here is the Overwrite property which is set to true: As a consequence, if the EAR file to be generated already exists, it will be overwritten. This might be problematic for archiving and tracking purposes but we'll handle that outside of the build file.

The build file is now nearly complete, we just need to add an additional build-all target which, as you've noticed, has been set as the default one in the very first part of the build file. This target will simply call the export-ear one which will result, through the mechanism of targets dependencies, into the successive call of all the previously defined targets:

<target name="build-all"
  description="Builds an application from scratch">
  <antcall target="export-ear"/>
</target>

The build file is now complete. We can run it to help ensure everything works properly. This means that we have to set all the previously mentioned properties. For that, we'll use the -D option of the build utility, which allows specifying a property as a name/value pair. The batch file used to run the build utility then looks like Listing 11, below.

set workspace=C:\CIEnv\workspace
C:\CIEnv\BuildUtility\eclipse\bin\runAnt.bat
  -Drad.preferences.filename=C:\CIEnv\workspace.epf
  -Drad.preferences.useeclipseprefs=true
  -Dprojects.name=EJB3Library,EJB3LibraryWeb,EJB3LibraryEAR
  -Dcopy.from.path=C:\CIEnv\EJB3Library
  -Dear.filename=EJB3Library.ear
  -Dear.project.name=EJB3LibraryEAR
  -verbose

Here, we assume that:

• Everything is located in a single C:\CIEnv folder;
• The build file is named build.xml;
• The workspace to be used is named workspace;
• The workspace preferences file is named workspace.epf (it is an epf file, so we also need to set the rad.preferences.useeclipseprefs property to true);
• The sample application source code is located into an EJB3Library folder.

We also define the -verbose option to get additional logs if ever something went wrong.

When running the batch file, or the shell script file on Linux, you'll get a several hundred lines long log (mainly due to the -verbose option). Even if the log says BUILD SUCCESSFUL at the end, it's still worth taking a look at it to fully understand what has happened. You'll be able to see which targets have been called and in which order, which internal operations the build utility performs, etc. You'll also be able to get compilation warnings or errors so that you can act on the workspace preferences if required.

The build file is now complete and fully functional. It's now time to use from within Hudson.

Back to top

Using Hudson to build your application

Hudson (see Resources) is an open source continuous integration server. It runs and monitors the execution of jobs which are made up of build steps. These build steps are defined using many different technologies, such as Ant, Windows batch commands, shell scripts, etc.

Hudson has many interesting features, such as the ability to run distributed builds (on several computers simultaneously), a wide use of RSS feeds (e.g. for notifications), and more. Take a look at the Hudson wiki (see Resources) to get an extensive description of Hudson's features.

Hudson is a Java 5.0 Web application. It is continuously enhanced by a very active open source community, with a new version made available every week or so. This community contributes a lot to the core of Hudson, both code and documentation, but also delivers their work through the notion of plug-ins: A plug-in is the way to extend Hudson. Dozens of them are already available, covering many different topics: Some of them allow to support new technologies as build steps (in this article, we're going to use the plug-in which adds the support for the build utility – see Resources), some others allow jobs to get their data from configuration management tools such as Rational ClearCase, some others allow to handle virtual machines, some others allows tweaking the Web UI, and so on. Just take a look at the list of available plug-ins (see Resources) to get an idea of their power: Their number and variety is impressive.

In this part, we're going to perform the following operations to use the build utility within Hudson:

• First, we'll see how you can quickly start Hudson.
• After, we'll install and set up the plug-in which adds the support for the build utility.
• Then, we'll create and set up a job which will use the build file we've built in the first part of this article.
• Finally, we'll run it to confirm everything works properly.

Starting Hudson

As previously mentioned, Hudson is a Java 5.0 Web application. It is then available as a WAR file which can be downloaded from Hudson's main site (see Resources). Here, we'll use the 1.312 release. We could have installed it on top of a servlet container such as Apache Tomcat (see Resources), but we'll use one of Hudson's nice features: The ability to be run outside of a servlet container by running the following command: java -jar hudson.war (you must use a JDK 5.0 or a JDK 6).

When run, this command will automatically start an embedded servlet container, making Hudson ready-to-use. Then, to access its Web UI, we just need to point our favorite Web browser to http://localhost:8080/.

Hudson's Web UI is fairly simple (see Figure 1), yet effective: It consists mainly in a sidebar located on the left of the screen and in a main panel all around. The two important items at this point are the Manage Hudson and New Job actions in the sidebar. The first one will allow us to set up Hudson, the second one will allow us to create our sample job.

But before going on, you may have noticed, in the logs displayed just after having run the Java command, that Hudson uses a home directory. This is because Hudson uses the filesystem to store the data it handles (configuration, jobs executions results, etc.) rather than a database.

By default, this home directory is named .hudson and is placed within the home folder of the user who runs the Java command. Of course, such a place may not be convenient in a production environment. This can be controlled by the use of the HUDSON_HOME variable. For example, to set Hudson's home folder to C:\CIEnv\hudson, just run the following command on Windows, set HUDSON_HOME=C:\CIEnv\hudson, before running java -jar hudson.war. Hudson will then place all its files within this directory.

Installing and setting up the Rational Application Developer Builder plug-in

Now that Hudson is running, we can install the plug-in, which will allow jobs to use the build utility. This plug-in is named Rational Application Developer Builder Plug-in (see Resources). We'll use version 1.1.2 which can be downloaded from Hudson's plug-ins site (see Resources) as an HPI file named rad-builder.hpi. Install it as follows:

• From Hudson's Web UI, go to Manage Hudson > Manage Plugins > Advanced.
• In the Upload Plugin section, browse to the rad-builder.hpi file you've just downloaded.
• Click on the Upload button (this action will upload rad-builder.hpi into the plug-ins folder which is inside Hudson's home folder).
• Once invited to do so, restart Hudson so that it is able to use the plug-in.

Before creating the job that will make use of the build utility, we need to do some additional setup. If you go to Manage Hudson > Configure System, which is Hudson's main configuration screen, you'll see that there is an IBM Rational Application Developer 7.0/7.5 section (see Figure 2). This section is contributed by the plug-in and is used to define where is installed the build utility, or even plain Rational Application Developer installations (the plug-in is currently compatible with versions 7.0 and 7.5 of Rational Application Developer).

In fact, this is possible to specify plain Rational Application Developer installations because, even if the build utility is a new tool delivered with Rational Application Developer 7.5, earlier versions of Rational Application Developer, such as the 7.0 one, are featuring the same capabilities, but directly embedded within the tool. For example, if you take a look at the bin folder of Rational Application Developer 7.0, you'll see that the runAnt.bat and runAnt.sh commands are available.

Let's go back to our IBM Rational Application Developer 7.0/7.5 section. It allows to define several installations: this is useful for example when you have to build some applications using Rational Application Developer 7.0 and some others using the build utility. In that case, you would define two installations.

To add an installation, just click on the Add Rational Application Developer button, set a name (e.g. BU 7.5) and specify the installation directory of the build utility (for example C:\CIEnv\BuildUtility). Then, save the changes.

Creating and setting up a new job

Now that the build utility installation has been defined in Hudson, we can create a new job which will use it. From Hudson's main screen, just click on New Job. You'll be asked to enter a job name, for example EJB3Library, and to select a job type: We'll use the Build a free-style software project one, which can be seen as the main possibility. Click on OK: The job configuration screen appears.

The job configuration is simple. At the very top of the job configuration screen, the user can define global options, such as adding build parameters, etc. At this point, you may have noticed the blue questions marks located at the right of each field. Just click on them to get an immediate help regarding the field they're attached to.

The user can then specify which software configuration management (SCM) tool is to be used in the Source Code Management section. Out-of-the-box, CVS and Subversion are available, but many others can be added using plug-ins, such as Rational ClearCase (see Resources). Note that in this article we don't make use of an SCM tool, but this is necessary. Continuous integration is mainly intended to be used by teams that collaboratively build software, and which needs to use an SCM tool to handle revisions, conflicts/merges, etc.

The next section the user can define is the Build Triggers. This is where the user defines when the job has to be run: A job execution can be triggered after another job execution has completed, or on a periodic basis (this can be used to trigger nightly builds), or based on a change in the SCM tool. It can also, of course, be triggered manually by a user.

The next section is the Build one. This is where we're going to use the build utility to generate the EAR file from our source code (see Figure 3). For that, click on the Add build step button and select the IBM Rational Application Developer 7.0/7.5 item. A new corresponding build step appears, with the Rational Application Developer installation field being normally already defined. This is followed by an optional Targets field where the user can define a list targets to be called by the build utility. If you click on the Advanced... button, you'll get additional fields:

• Build file is where the user sets the name of the build file to be used by the build utility. By default, the build step searches for a file called build.xml located in the workspace of the job.

The workspace of a job is different from the Rational Application Developer workspace: this is a folder specific to each Hudson job, which is simply named workspace, and is created just before the job is run for the first time (note that this behavior changes when using Hudson in a distributed environment). Once you'll have run the job at least one, and assuming the Hudson's home folder is C:\CIEnv\hudson, the workspace folder will be C:\CIEnv\hudson\jobs\EJB3Library\workspace.

So, we'll set this field to ..\..\..\..\build.xml, which corresponds to the path of C:\CIEnv\build.xml relatively to the job's workspace.

• Rational Application Developer workspace is the field where the user can define the name of the Rational Application Developer workspace to be used by the build utility. This field is optional, as are all the others. For this article, we'll keep it empty.
• Create PROJECT_WORKSPACE variable is an interesting feature (but we won't use it): Normally, Hudson automatically creates a WORKSPACE variable that jobs can use to run some actions on their workspace. But, here, this variable actually refers to the Rational Application Developer workspace. This feature then allows to create a new PROJECT_WORKSPACE variable that refers to the job's workspace.
• Remove Rational Application Developer workspace content is a nice feature: When this field is checked, the Rational Application Developer workspace is deleted, if it already exists, before the build utility is actually invoked. This is useful to ensure, as already mentioned, that the build utility uses a clean Rational Application Developer workspace, avoiding common pitfalls. Here, we'll check it since our build file copies the projects into the Rational Application Developer workspace each time it is run. Again, the source code should normally be obtained from the SCM tool.
• When checked, the Remove only Rational Application Developer workspace metadata folder field will simply remove the .medata folder of the Rational Application Developer workspace before the build utility is run. Every other files located in the Rational Application Developer workspace will remain as-is.
• The Properties field also interests us: This is where we will define all the properties used by our build file. As a consequence, we'll set this field as follow so that our build file gets all the properties it needs when it is run.

rad.preferences.filename=C:/CIEnv/workspace.epf
rad.preferences.useeclipseprefs=true
projects.name=EJB3Library,EJB3LibraryWeb,EJB3LibraryEAR
copy.from.path=C:/CIEnv/EJB3Library
ear.filename=EJB3Library.ear
ear.project.name=EJB3LibraryEAR

Note that we've changed from backslashes to slashes as a path separator.

Tip: If you define several build steps, you can reorder them by dragging and dropping them where you want them to go.

After we have defined the build step, take a look at the Post-build Actions section. It allows you to define actions that are to be performed after the build steps have completed. User can requests Hudson to trigger the execution of other jobs, or to send notification e-mails, etc. One other feature that is interesting is the Archive the artifacts one: When set, Hudson will automatically archive a set of user-defined artifacts (for example, EAR files) that have been generated during the build, which is why we didn't care, in the first part of this article, about saving the older EAR files before new ones are generated.

The job configuration is now complete. We can save it, which will bring us to the job's main screen, and then we can run the job by clicking on the Build Now action. A blinking item will briefly appear in the Build History panel, representing the job currently being executed. Once the execution gets completed, it should stop blinking while displaying a blue bullet, meaning the job successfully ended.

To help ensure everything worked properly, we can do two things:

• First, we can ensure that the EAR file has been properly created: As the earExport task uses its base directory to generate the EAR file, it means that EJB3Library.ear is created in C:\CIEnv.
• Then, back to Hudson's Web UI, in the Build History panel, we can click on the line corresponding to the execution of our build. We're provided with several new actions, one the most important being the Console Output one: If you click on it, you'll be provided with all the logs produced during the execution of the job (and, thus, the build utility logs).

Another important item, which is not currently activated, is the No changes option. If we were using an SCM tool, we would get there a comprehensive list of all the changes that happened in the SCM tools before the build took place.

Note that the link in the Build History panel can be clicked while the execution is taking place, allowing for example to get an access to the logs in a real-time manner.

Back to top

Going further

This article covers only the build applications process using a continuous integration server. This is just a start, and additional tasks such as plugging the continuous integration server to an SCM tool, running unit tests, deploying the application on runtime environments, and triggering the execution of regression tests

are required to use a fully-functional continuous integration environment.

Back to top

Conclusion

In this article, we've seen how the Rational Application Developer build utility can be used to build applications designed with Rational Application Developer.To achieve this, we've created a simple yet generic build file that, from a set of Rational Application Developer projects, generates an EAR file. We've then installed and set up the Hudson continuous integration server, and we've created a Hudson job that uses the build utility to finally produce the EAR file. Now you can build headless applications and leverage them in a continuous integration environment.

Back to top

Download

Information about download methods

Resources

Learn

• Rational Application Developer 7.5 Information center: The number one place to get all you need to effectively use Rational Application Developer.
  
  
• Hudson's main Web site: The central place where to get all you need on Hudson.
  
  
• Meet Hudson: An overview of Hudson's main features, on the Hudson wiki.
  
  
• Hudson's plug-ins: A list with most of the available plug-ins for Hudson.
  
  
• Rational Application Developer Builder Plug-in: User guide for Hudson's Rational Application Developer Builder plug-in.
  
  
• ClearCase Plug-in: User guide for Hudson's ClearCase plug-in.
  
  
• Learn about other applications in the IBM Rational Software Delivery Platform, including collaboration tools for parallel development and geographically dispersed teams, plus specialized software for architecture management, asset management, change and release management, integrated requirements management, process and portfolio management, and quality management.
  
  
• Visit the Rational software area on developerWorks for technical resources and best practices for Rational Software Delivery Platform products.
  
  
• Explore Rational computer-based, Web-based, and instructor-led online courses. Hone your skills and learn more about Rational tools with these courses, which range from introductory to advanced. The courses on this catalog are available for purchase through computer-based training or Web-based training. Additionally, some "Getting Started" courses are available free of charge.
  
  
• Subscribe to the IBM developerWorks newsletter, a weekly update on the best of developerWorks tutorials, articles, downloads, community activities, webcasts and events.
  
  

Get products and technologies

• Ant-Contrib: Download Ant-Contrib to help keeping build files as generic as possible.
  
  
• Hudson: Download the 1.312 release of Hudson.
  
  
• IBM Rational Application Developer for WebSphere Software trial version: Download the latest version of Rational Application Developer.
  
  
• Rational Application Developer Builder Plug-in: Download the 1.1.2 release of the Rational Application Developer plug-in for Hudson.
  
  
• Tomcat: Download the Tomcat servlet container to run your Hudson server.
  
  
• Download trial versions of IBM Rational software.
  
  
• Download these IBM product evaluation versions and get your hands on application development tools and middleware products from DB2®, Lotus®, Tivoli®, and WebSphere®.
  
  

Discuss

• Check out developerWorks blogs and get involved in the developerWorks community.
  
  

About the author

Romain Seguy is a methods and tools expert working for Michelin. Seguy works with Java™ technology, delivering effective tools like complete software development platforms to a large community of developers. Seguy is currently building an extensive continuous integration environment to build, test and deploy applications based on a diverse array of technologies (Java, DataStage, etc.), and holds a master's degree in computer science, specializing in software engineering.

Rate this article

Comments

Back to top

Table of contents

• Introduction
• Creating a build file for use with the Rational Application Developer build utility
• Using Hudson to build your application
• Going further
• Conclusion
• Download
• Resources
• About the author
• Comments

Next steps from IBM

• Try: Rational Application Developer for WebSphere Software
• Buy: Rational Application Developer for WebSphere Software

Dig deeper into Rational on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

Get started with the cloud-based trial and pattern development kit.

Special offers