In this chapter, we look at Continuum (http://maven.apache.org/continuum/). Continuum^[5] is a flexible, easy-to-use tool that can help you put Continuous Integration into action. It is fast, lightweight, and undemanding. It is also self-reliant. Like Maven, it is built on the Plexus component framework and comes bundled with its own Jetty application server. For its database needs, it uses Apache Derby, a 100 percent Java fully embedded database. As we will see, this makes Continuum particularly easy to install in almost any environment.

Installing a Continuum server is easy. Make sure that you have a recent Java Development Kit (JDK) installed (and JAVA_HOME defined) and download the appropriate installation package from the Continuum web site. I used Java 5 for this chapter.

Continuum, like other Continuous Integration tools, uses locally installed tools to check out source code and build your project. So, if you are using Maven and Subversion on your projects, you will need to install these tools on your build machine.

Next, just extract the downloaded file into the directory where you want to install Continuum. Extracting the installation package is pretty much all you need to do to get a basic server up and running.

If you are installing Continuum onto an integration server, you will probably need to have Continuum starting automatically. Continuum comes with a useful wrapper program and an installation script in the binwin32 directory called InstallService:

D:continuuminwin32>InstallService
wrapper  | continuum installed.

This will install a standard Windows service, which you can manage in the usual manner from the Services window (see Figure 5-1). By default, the service will run as the local system account and will be unable to access all of the resources that it needs to start up Continuum. To get around this, you will need to start the service as the same user account in which you installed Continuum. To do this, open the service properties window and change the account used to start the service in the tab “Log On.”

Figure 5-1. Continuum as a Windows service

For Debian-based Linux systems, you can do the following: first, extract Continuum into your /usr/local/ directory. Then, for ease of maintenance, create a symbolic link to this directory called continuum:

# ln -s continuum-1.1/ continuum
# ls -dl continuum*
lrwxrwxrwx  1 root root   16 2006-04-29 10:10 continuum -> continuum-1.1/
drwxr-xr-x  9 root root 4096 2006-04-29 10:10 continuum-1.0.3

It just so happens that the Continuum Linux startup script takes the same arguments as the classic Linux boot scripts that we all know and love. So, all you need to do is to update a symbolic link to this script in your /etc/init.d directory, as follows:

ln -s /usr/local/continuum/bin/Linux/run.sh /etc/init.d/continuum

Then, you will need to set up symbolic links in the appropriate /etc/init.d subdirectories. Here’s what it looks like on my Suse machine:

# ls -al /etc/init.d/*/*continuum
lrwxrwxrwx  1 root root 12 2006-05-16 01:07 /etc/init.d/rc2.d/K21continuum -> 
../continuum
lrwxrwxrwx  1 root root 12 2006-05-16 01:07 /etc/init.d/rc2.d/S01continuum -> 
../continuum
lrwxrwxrwx  1 root root 12 2006-05-16 01:07 /etc/init.d/rc3.d/K21continuum -> 
../continuum
lrwxrwxrwx  1 root root 12 2006-05-16 01:07 /etc/init.d/rc3.d/S01continuum -> 
../continuum
lrwxrwxrwx  1 root root 12 2006-05-16 01:07 /etc/init.d/rc5.d/K21continuum -> 
../continuum
lrwxrwxrwx  1 root root 12 2006-05-16 01:07 /etc/init.d/rc5.d/S01continuum -> 
../continuum

In fact I cheated—the Suse graphical control center (YasST) lets you set up all these links quickly and painlessly. Similar tools exist in other flavors of Linux as well.

Now that Continuum is correctly installed, you can display the Continuum web administration console at http://localhost:8080/continuum. The first time that you start Continuum, you will need to provide an admin account username and password (see Figure 5-2).

Figure 5-2. Continuum needs to be configured the first time you start it up

On the following screen, you can configure the application work directories (see Figure 5-3). Unless you are setting up a fairly sophisticated installation, you can leave the working directory and build output directory fields with their default values.

Figure 5-3. Continuum needs to be configured the first time you start it up

The (optional) Deployment Repository Directory lets you set up a Maven repository where generated products will be deployed. This will typically be a local Enterprise repository (see Setting Up an Enterprise Repository with Archiva), and can be a useful way to provide users with access to automatically deployed snapshot builds. Each snapshot will have a unique timestamp, making it easy to integrate and test particular snapshots in other projects (see Figure 5-4).

Figure 5-4. Continuum can automatically deploy snapshots to a local enterprise repository

The base URL is the public URL that will be included in email notifications to encode links to build results. This is useful if Continuum is running behind a web server. This often defaults to a local host address, which is fairly useless for anything other than local testing, so make sure you change this field to something sensible for any live installations.

You can also tailor company-related information in the “Appearance” screen. This lets Continuum customize the web site somewhat by displaying your company logo in the top right corner of the screen.

Once you validate this data, all subsequent connections will go directly to the Continuum administration page (see Figure 5-5). All users can consult the standard view, which shows the build status of the different projects on the server. To do any configuration, such as adding or configuring projects or project groups, you need to log in using the administration login you provided earlier.

Figure 5-5. The Continuum administration home page

There are basically two ways to start and stop the Continuum server manually.

First, you can start the server using one of the environment-specific start scripts. The basic way to start the server from the command line is as follows:

The basic way to start the server from the command line is to run the start command as follows:

# /usr/local/continuum/bin/Linux/run.sh start
Starting continuum...

Of course, if you have followed the Linux installation procedure described above (see Installing a Continuum Server), you can also do the following:

# /etc/init.d/continuum start
Starting continuum...

You can also restart the server using the (wait for it!) restart command:

# /etc/init.d/continuum restart
Stopping continuum...
Stopped continuum.
Starting continuum...

And to stop the server, just use the stop command:

# /etc/init.d/continuum stop
Stopping continuum...
Stopped continuum.

Operating systems being what they are, you may sometimes need to check if Continuum is running correctly. If the process seems to have hung, you can always use the status option to check if there is a process running, and, if so, what its Process Identification (PID) number is. The PID number can always come in handy if you need to kill the process at some point:

$ /usr/local/continuum/bin/Linux/run.sh status
continuum is running (16259).

This information is actually stored in a file called continuum.pid, in the same directory as the startup script. So, if you accidentally remove this file, the status option can get quite confused.

If you need to see more details about what the Continuum server is doing (usually to identify and fix a problem), you can always start the server in console mode:

# /etc/init.d/continuum console
Running continuum...
wrapper  | --> Wrapper Started as Console
wrapper  | Launching a JVM...
jvm 1    | Wrapper (Version 3.1.2) http://wrapper.tanukisoftware.org
jvm 1    |
jvm 1    | [INFO] Services will be deployed in: '../../services'.
jvm 1    | [INFO] Applications will be deployed in: '../../apps'.
jvm 1    | [INFO] The application server has been initialized.
...

This will display ample details of what the server is getting up to, and hopefully it will also show what is going wrong.

Once the server is running, you can add some new projects to the Continuous Build system. If you’re not logged on, you will need to do this first.

In Continuum, projects are organized into groups. The installation comes with a default group (called, rather unimaginatively, “Default Project Group”), but you can create as many of your own groups as you like, depending on your needs. Once you have created a group, you can then proceed to creating projects within this group (see Figure 5-6).

Figure 5-6. Adding a Maven 2 project

Now that we have a group, let’s add a Maven 2 project. Because of the particularly close integration with Maven 2, this sort of project is easy to add. Continuum simply reads the pom.xml file and gets all the information it needs there (see Figure 5-7). You can either upload a POM file from your local machine, or specify a URL pointing to the POM file on some accessible repository. If you want to follow along at home, you can go pick your favorite Maven-powered open source project, or use the following publicly available URL:

https://wakaleo.devguard.com/svn/jpt-sample-code/maven-schemaspy-plugin/trunk/pom.xml

Figure 5-7. Adding a Maven 2 project

Not just any old Maven 2 project will do, however. Your Maven 2 project needs to provide a minimum of useful information to make Continuum happy, so you should check that your project file is correctly configured.

In fact, the only really essential information is the Software Configuration Management (SCM) details, which you probably already have. Check out the SCM section of your project’s pom.xml file. You need the connection element to be correctly configured with your local SCM system. Here is an example using Subversion:

    <scm>
      <connection>
        scm:svn:https://wakaleo.devguard.com/svn/maven-plugins
        /maven-schemaspy-plugin/trunk
      </connection>
      <developerConnection>
        scm:svn:https://wakaleo.devguard.com/svn/maven-plugins
        /maven-schemaspy-plugin/trunk
      </developerConnection>
      <url>
        https://wakaleo.devguard.com/svn/maven-plugins/maven-schemaspy-plugin/trunk
      </url>
    </scm>

The syntax used is that of the Maven SCM project (see A Human-Readable Project Description” in Declarative Builds and the Maven Project Object Model). The Maven SCM project (and therefore Continuum) currently support CVS, Subversion, ClearCase, Perforce, Starteam, and Bazaar, although support for other SCM tools such as PVCS, MKS, and Visual SourceSafe is planned.

One thing worth knowing is that Continuum expects your pom.xml file to be in the project root directory. Should this not be the case (for example, if you are checking out a from a higher-level directory in your source code repository), you need to provide a relative path to the pom.xml file in your build definitions.

Continuum will read other details if they are available. In Continuum, each project has a list of developers. Continuum can read the developer team details list from the pom.xml file, if this information is present. The list typically includes an entry for each developer, including (at least) their system login, name, and email. In the current version, this information is just for informative purposes. Future versions of Continuum might use this information directly for mail notifications. An example is shown here:

  <developers>
    <developer>
      <id>duke</id>
      <name>Duke Java</name>
      <email>[email protected]</email>
      <role>Super developer</role>
    </developer>
    ...
  </developers>

Finally, you can configure the ciManagement section, if it is not already done. This section contains the URL for the project Continuum site (so that a link can be displayed on the Maven-generated project web site) and a list of notifiers. The notifiers tell Continuum how to inform developers in the developer list about the build results. There are many different types of notifiers available, including email, and several types of Instant Messagers (IRC, Jabber, and MSN). In the current version of Continuum, you need to provide one (or more) individual notifier for each developer in your team:

  <ciManagement>
    <system>continuum</system>
    <url>http://mybuildserver:8080/continuum</url>
    <notifiers>
        <notifier>
          <type>mail</type>
          <configuration>
            <address>duke</address>
          </configuration>
        </notifier>
        </notifier>
    </notifiers>
  </ciManagement>

You can also add notifiers very easily directly from the Continuum web interface (see Setting Up Notifiers).

Once you have added your project, it will appear in the list of projects for this group (see Figure 5-8).

Figure 5-8. The new project appears in the project group list

Maven 1 projects can be added in the same way, by simply providing the Maven 1 project.xml file.

If you want to add an Ant project to your Continuum server, you need to provide a little more detail, simply because this information isn’t present (or at least not in an easy-to-find format) in the build.xml file. Just enter a project name and version (for display purposes), and the relevant SCM details (see Figure 5-9). Note that the SCM URL uses the Maven format for SCM URLs (see The Source Repository). The SCM URL should point to the project’s root directory.

Again, you can follow along at home by using the following URL:

https://wakaleo.devguard.com/svn/jpt-sample-code/jsfpetstore/trunk

Figure 5-9. Adding an Ant project to Continuum

By default, Continuum expects to find a file called build.xml in this directory. If your project is configured differently, you need to edit the build configuration once you have created the project (see Configuring and Scheduling Builds).

You can even add a project that is built via an OS-specific script. I once worked on a project where we used a plain old Makefile to read environment-specific variables from a local configuration file, and then call Maven. Other examples could be when OS-specific initialization or cleanup tasks need to be done before or after the main build task.

The script must respect a few conditions: it should call Maven at some point, and it should return a result value of 0 for success and 1 for failure.

Setting up a script in Continuum is similar to setting up an Ant project (see Adding an Ant Project). You just provide a name and version and appropriate SCM information.

Continuum provides a convenient dashboard where you can see the status of all your projects at a glance (see Figure 5-10). Projects are organized in groups, which is convenient because, in practice, you will often have several build projects for a given development project.

Each project is listed with an icon indicating the current build status (1). See the following table.

	Success—The last project build was an unqualified success.
	Failure—Uh-oh. There is a problem of some kind, such as a compilation error or unit test failures. The build history screen will help isolate the exact problem.
	Error—A major stuff-up has occurred. This is often a configuration error or a problem with obtaining the source code from the version control system. Checkout the build history for more details.

In the Build column (2), you will find the number of attempted integration builds that have taken place since the project was added to Continuum. Special icons will sometimes appear here if a build is queued or in progress.

Figure 5-10. The Continuum project dashboard

Further to the right (3), we have a set of useful little icons, which allow you (going from left to right) to force an immediate build (useful to verify whether the correction you just committed has fixed the integration problem detected by Continuum), to display the build history, and to display the working copy used by Continuum for its builds.

If you click on the project name, you can view and modify the build configuration details (see Figure 5-11). This is a useful screen where you can configure and schedule build targets, set up notifications, and (for Maven projects) display project dependencies and team details. We will look at this page in more detail later on.

Figure 5-11. The Continuum Build Configuration details

The Build History page lets you consult a list of all builds for this project (see Figure 5-12).

Figure 5-12. The Continuum Build History page

You can also display detailed results for each build, including changes made to the source code repository and the appropriate build logs (see Figure 5-13). This is very useful for debugging an integration error.

Figure 5-13. A Continuum build report

Finally, the Working Copy page lets you browse through the version of the project source code that Continuum is currently using for its builds. This is useful to check whether Continuum is using the version you think it is. Don’t forget, Continuum gets its source code from the version control repository, not from your machine, so there may be differences.

Continuum provides good support for user management. As you might expect, you add or delete users as required in the “Users” screen (see Figure 5-14). This screen also lets you define user roles for each user, either in terms of global roles that apply across all projects (such as “System Administrator” or “Guest”), or, more specifically, for individual projects. For specific projects, you can define a user as being a Project Administrator (who can do pretty much anything within that particular project), a Project Developer (who can start builds), or a Project User (who can consult the build results).

Figure 5-14. A Continuum build report

Receiving notification by mail is all very well, but sometimes mail is slow to arrive, or it can be ignored. Continuum provides for a few other notification mechanisms, such as various forms of chat and instant messaging. At the time of this writing, these current mechanisms were supported:

All of these are fairly easy to configure from the Continuum web console. When you configure instant messaging, you will need to set up a special account with your messaging service for the Continuum server. Most instant messaging services don’t appreciate users being logged on simultaneously in several different places, so you can’t use an account that is already being used by someone in the development team.

The main problem with Continuum notifications is that you need to set them up one-by-one for each project team member, even if the members are defined in the POM file.

There is no out-of-the-box support for RSS, although this is not hard to implement using the Continuum RCP Application Programming Interface (API).

As far as builds are concerned, the term “Continuous Integration” is inexact: “Regular Automatic Integration” would be closer, but it probably doesn’t sound as snappy. In any case, builds on a Continuous Integration server need to be scheduled carefully: too few, too far apart, and you lose in reaction time; too many, too close together, and your server may go down. And if you have several projects on the same server, it’s advisable to schedule them in a way that avoids all the projects being built at the same time.

As you would expect, Continuum lets you set up build schedules for your projects (see Figure 5-15). You can define as many build schedules as you like, giving them (hopefully) meaningful names and planning the builds using the superbly powerful, if somewhat cryptic, Cron expression syntax. A detailed description of the Cron syntax can be readily found on the Internet, but we’ll give a brief description here for clarity.

Cron expressions are a precise, concise, and flexible way of describing exactly when a task should be performed. In Continuum, a Cron expression is composed of seven fields, which represent seconds, minutes, hours, days of the month, months, days of the week, and years (see Table 5-2).

There are also some important special characters:

Here are a few useful examples:

Figure 5-15. Adding a schedule in Continuum

At the scheduled time, the source code repository will be queried for changes. If any changes are detected, then the build will be run.

Now, each project has a list of build definitions (see Figure 5-16). For Maven projects, it comes with a default one set to “mvn clean install,” as you may not have noticed when you created your projects. For Ant, the default build definition will simply invoke default goal in the build.xml file at the project root.

You can, of course, modify these default build definitions for your project, and you can also add as many additional goals as you like (see Figure 5-16). For example, you might want an hourly continuous build schedule for integration tests and a nightly deployment of the Maven web site. In this case, you just create a “NIGHTLY BUILD” schedule, add a new build definition to your project with an appropriate goal (for example, “clean site site:deploy” for a Maven 2 project), and finally assign the “NIGHTLY BUILD” schedule to this build definition.

Figure 5-16. Adding a new build definition

Once you set up your build, you need to ensure that it runs correctly. Otherwise, you may find yourself overwhelmed by a flood of abusive email from irate developers who have been told (incorrectly, for once) that their build is broken.

When you add a build, you can either wait for it to run automatically or, better still, trigger a build by hand to make sure it works. If it fails, you can check out exactly what happened in the “Result” screen, which you can access through the link of the same name in the Builds tab. This screen shows the raw output of your build execution, which is often enough to isolate and correct the problem.

Another useful tool is the Working Copy tab. Here you can view the directory structure and files that Continuum used for the build. You can compare this with your own local copy to make sure all the necessary files are there, and that their content is correct.

The Continuum web site provides a good summary of the project build status, but developers cannot be expected to stay glued to the screens watching it—they have to write code from time to time, too! As we have seen (see Setting Up Notifiers), that’s what notifiers are for.

By default, the mail notifier will attempt to use the mail service installed on the machine where Continuum has been installed. The default configuration expects to find a Simple Mail Transfer Protocol (SMTP) server on the local machine (local host) using the standard SMTP port (25): this will work fine for most Linux or Unix environments with a mail service installed.

However, you may need to configure the mail server for Continuum if you are not sending mail directly via a service on the server. To do this, you need to modify the application configuration file, which can be found at apps/continuum/conf/application.xml. This is the Plexus framework configuration file for your Continuum server, and as such should be treated with due caution and respect. The bit you need to look for is the MailSender component: modify the values to suit your environment. Here is one possible configuration:

    <component>
      <role>org.codehaus.plexus.mailsender.MailSender</role>
      <implementation>org.codehaus.plexus.mailsender.javamail.JavamailMailSender
      </implementation>
      <configuration>
        <smtp-host>smtp.mycompany.com</smtp-host>
        <smtp-port>25</smtp-port>
        <sslProvider>com.sun.net.ssl.internal.ssl.Provider</sslProvider>
        <username>mylogin</username>
        <password>mypassword</password>
        <sslMode>true</sslMode>
      </configuration>
    </component>

It’s worth taking some time to think about how build results are going to be published. As a rule, for example, notifications for successful builds are of limited value to anyone except (possibly) the developer who just committed some changes. Failures, warnings, and errors, by contrast, should definitely be required reading for the whole team. Using a mailing list for noncritical messages is often a good compromise.

Continuum lets you configure notifiers to be sent on errors, warnings, failures, and/or successful builds, so you have a fair bit of flexibility at your disposal.

By default, Continuum runs its web server on port 8080, and listens for XML-RPC requests on port 8000. Of course, this may not suit everyone. To change these ports, you need to modify the following configuration file:

apps/continuum/conf/application.xml

Edit this file and find the services section. In the following listing, the port is set to 8081 instead of the default 8080:

 <services>
   <service>
      <id>jetty</id>
      <configuration>
        <webapps>
          <webapp>
            <file>${plexus.home}/lib/continuum-web-1.0.3.jar</file>
            <context>/continuum</context>
            <extraction-path>${plexus.home}/webapp</extraction-path>
            <listeners>
              <http-listener>
                <port>8081</port>
              </http-listener>
            </listeners>
          </webapp>
        </webapps>
      </configuration>
    </service>
    ...

Now just restart the Continuum server.

As of Continum 1.1, you can also configure the port in the conf/plexus.xml file, as shown here:

<plexus>
    ...
    <!-- START SNIPPET: jetty_port -->
    <component>
      <role>org.codehaus.plexus.contextualizer.Contextualizer</role>
      <role-hint>jettyConfiguration</role-hint>
      <implementation>org.codehaus.plexus.contextualizer.DefaultContextualizer
      </implementation>
      <configuration>
        <contextValues>
          <jetty.port>8081</jetty.port>
        </contextValues>
      </configuration>
    </component>
    ...
</plexus>

One of the nice features of Maven is its built-in ability to generate a web site containing an abundance of technical information and reports about your project (see Chapter 29). One common use of Continuum is to automatically generate and publish this web site.

The standard way to build a Maven web site is to run the following command:

$ mvn site

This will generate a Maven site in the target directory. However, it is of limited use there. You generally want to copy it to a local web server, in order to publish your site to the world (or even just for your fellow workers). One simple (some would say “quick and dirty”) way to do this is to use the stagingDirectory variable. The following code will generate a Maven site and publish it in the /var/www directory:

$ mvn site -DstagingDirectory=/var/www

This will deploy your Maven web site to the /var/www directory, in a directory with the same name as your project.

Typically, you run CI builds regularly. If the build fails, the build indicator goes red, notifications are sent, and the build stops. This is fine for detecting build failures, but is less satisfactory if you need to publish a web site to display, among other things, details of these build failures.

The conventional way to do this is to use two distinct build tasks: one to build the application and run the unit and integration tests, and another to publish the web site. The first should fail if there are any test failures, the second should not. To prevent a Maven target from stopping in the presence of unit test failures, use the maven.test.testFailureIgnore command-line option, as shown here:

$ mvn site -DstagingDirectory=/var/www -Dmaven.test.testFailureIgnore=true

This is illustrated in Figure 5-17, in which the Maven site is updated every hour, even if there are unit test failures.

Figure 5-17. Building the Maven site with hourly builds

Another approach, originally suggested by Max Cooper,^[*] is to set up a profile in which test failures are ignored.

<!-- skip tests by default, but allow override on command line --> 
<profile> 
    <id>skiptests</id> 
    <activation> 
        <property> 
            <name>!maven.test.skip</name> 
        </property> 
    </activation> 
    <properties> 
        <maven.test.skip>true</maven.test.skip> 
    </properties> 
</profile>

Then, just run your site generation normally:

$ mvn site:site

Continuum is without doubt a useful tool for optimizing the build process. Developers will appreciate getting quick feedback on any new integration issues thanks to regular automatic builds. However, in real-world projects, not all builds are automatic. For example, in a test or staging environment, you generally want to decide yourself when a new version is to be released onto the test environment, rather than doing it automatically. Test releases need more coordination and communication efforts than regular automatic builds for developers: test teams appreciate being able to test on a stable, well-defined version, and not be confronted suddenly by the latest snapshot.

As we have seen, Continuum makes it easy to set up one or several automatic builds. You can also use Continuum to make your life easier when you build the release versions of your product. This way, releases can be done directly from the Continuum web interface, in a controlled environment, rather than on a developer’s machine.

To do this, you need to set up a schedule that is never actually run. We will use this special schedule to define tasks that are to be activated manually.

Create a new schedule, with a name like “MANUAL_TASK.” You will need to provide a syntactically correct CRON expression, although you may want to give an impossible value such as a past date (e.g., “0 0 12 * * ? 1999” ) or one far in the future (e.g., “0 0 12 * * ? 2099” ) to make your intention clear. As we will see, this value will not actually be used. Just make sure that the schedule is disabled (uncheck the “Enabled” checkbox at the bottom of the screen) and save.

Now you need to create an additional build target for your manual build. This can be a separate project or an additional build target within the same project. In both cases, you will end up with a build definition like the second one in Figure 5-18.

Figure 5-18. A project containing manual build definitions

Next, you need to distinguish the target environments, so that your manual task deploys to your staging environment. In Ant, you might do this using command-line property definitions or by calling a different target, for example. The above example is for a Maven 2 project. Maven profiles (see Defining Build Profiles” in Declarative Builds and the Maven Project Object Model) are a good way to customize environment-specific deployment details. You can set up profiles for each target environment in your pom.xml or profiles.xml file, as shown here:

<!-- Staging environment profile --> 
<profile> 
    <id>env-staging</id> 
    <activation> 
        <property> 
            <name>environment</name> 
            <value>staging</value> 
        </property> 
    </activation> 
    <properties> 
        <appserver.autodeploy.dir>/appserver/staging/myapp/webapps
        </appserver.autodeploy.dir>
    </properties> 
</profile> 

<!-- Integration test profile --> 
<profile> 
    <id>env-test</id> 
    <activation> 
        <activeByDefault>true</activeByDefault> 
        <property> 
            <name>environment</name> 
            <value>test</value> 
        </property> 
    </activation> 
    <properties> 
        <appserver.autodeploy.dir>/appserver/test/myapp/webapps
        </appserver.autodeploy.dir> 
    </properties> 
</profile>

Two profiles are defined: one for an integration test environment (identified by setting the “environment” variable to “test”) and one for a staging environment (identified by setting the “environment” variable to “staging”). Each has its own definition of the appserver.autodeploy.dir property, which is used to indicate where to place the generated application (WAR).

Note that if you are using profiles in this way, it is wise to set up a separate Continuum project for each profile. This is because Continuum uses the same work directory for all the builds for a given project. So, if you use two different profiles in builds in the same Continuum project, you run the risk of overriding your generated artifacts with versions using the wrong profile. This feature is not particularly well supported in Continuum, as Maven 2 projects are listed by their project name in the list of Continuum projects. If you create multiple projects using the same POM file, they will appear as identical entries in this list.

The other main disadvantage of this approach is that you have less control over the exact version you are releasing. You cannot specify a particular Subversion or CVS tag to release, for example, without modifying the task goal to include the revision tag you need.

Continuum is still a relatively young product, with a lot of room for new and improved features. It has, nevertheless, made a lot of progress since it first appeared. It is easy to install and easy to use and will suffice in many situations. Its simplicity and its intuitive web administration console make it a good candidate for introducing continuous integration into organizations that have had no previous experience with the subject.

On the negative side, Continuum lacks some of the more advanced features found in other tools, although this has greatly improved since the release of Continuum 1.1.