Two Guys Arguing

Custom Continuum Notifier – Step 2: Build a dummy notifier

Posted in java by benjaminplee on 08.07.09

Now that we have Continuum building without any problems, the next step is getting a basic notifier coded up and Continuum aware of it.

The Continuum user wiki makes this process seem simple enough:  create a new notifier extending AbstractContinuumNotifier and register the new notifier in application.xml.  Essentially, this is true … with a few minor modifications.

  1. Create your new notifier project
    1. Under the continuum-notifiers Maven module, create a new module called continuum-notifier-web as a standard Maven project (or dupe one of the existing ones)
    2. Modify the new module’s pom.xml to have continuum-notifiers as its parent and add the continuum-notifier-api artifact as a dependency
    <project ...>
     <name>Continuum :: web-Dashboard</name>
    1. Add the new sub-module to the continuum-notifiers parent pom.xml.
  2. In your new project, create a basic notifier that simply logs that it was called.  This class should extend AbstractContinuumNotifier and implement getType() and sendMessage():
package org.apache.maven.continuum.notification.atkpwadashboard;

import org.apache.maven.continuum.notification.AbstractContinuumNotifier;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class WebNotifier extends AbstractContinuumNotifier {
 private Logger log = LoggerFactory.getLogger(getClass());

 public String getType() {
 return "web";

 public void sendMessage(String messageId, MessageContext context)
 throws NotificationException {"Web Notifier has been called!");
  1. Build your new module either by a full build of Continuum or by just building your sub module (mvn package).
  2. Deploy your new notifier
    1. Copy the newly created notifier .jar into your Continuum intallation at <CONTINUUM_BASE_DIR>/apps/continuum/WEB-INF/lib/continuum-notifier-web.jar
    2. Modify <CONTINUUM_BASE_DIR>/apps/continuum/WEB-INF/classes/META-INF/plexus/application.xml to register the new notifier by adding the following code:
  3. Restart Continuum
  4. On one of your managed applications, modify the pom.xml to use the new notifier:
  1. Profit.

Things to note:

  • Continuum uses Plexus for its dependency injection.  Since your notifier is extending AbstractContinuumNotifier which has dependencies, you MUST register your notifier as needing these inject or you will see some lovely and confusing NullPointerExceptions when you try to use the notifier.
  • Technically you don’t need to get Continuum to compile to build a new notifier, but having the source handy and being able to see how the rest of the project is structured helps.
  • I haven’t figured out how to get Continuum builds to auto install my notifier yet …. it is on my to-do list.
  • To simplify creating the new project, I just copied continuum-notifier-jar and made modifications as necessary.
  • The email notifier is called “mail” and is in the continuum-core module.

Big Frustrating Gotcha:  Continuum’s notifier plugin architecture only extends to the internals of Continuum but does NOT include any of the web-app’s GUI.  This means that your new notifier will not show up in any of the admin screens as an option, or have any edit/configuration screens a web user can see.  These GUI elements are managed in the continuum-core and continuum-web-app modules, separate from the notifier code themselves.  For what I was doing I didn’t need this, but it would have been nice.  It looked to be fairly simple to add the new notifier to the approrpiate .jsp’s and have full graphical interface power.

Helpful Links:

  • Continuum user wiki page on building a notifier
  • Email chains one and two talking about doing the same thing
  • Configure your notifier in the application.xml wrong and you might get an error like this

Last step is to make the notifier actually do something related to build ….

Tagged with: , ,

Custom Continuum Notifier – Step 1: Get Continuum to Compile

Posted in java by benjaminplee on 08.06.09

report card

This past week I was charged with creating a custom Continuum notifier which would push a build’s Selenium TestNG test results to a second system for reporting.  Changing project priorities, distractions, poor documentation and some weird issues made this simple task take much longer than it should have.  Hopefully, this series of posts will help make the process just a little bit smoother for the next person.


Visibility into the quality of a software project is crucial to delivering a top notch product.  One direct way to achieve this is monitoring the team’s UAT results over time.  I have been slowly pushing the client’s development teams to fully automate their user acceptance testing along side the rest of their build process.  Enter Continuum and Maven, the client’s choices for continuous integration and “one button” builds.  Out of the box, Continuum had pretty much everything we needed from a testing/reporting standpoint, except that the development teams were spread out across several Continuum installations and management wanted a single place to see ALL teams’ test results.  Luckily, I found that Continuum has a plugin architecture for its notifiers – the plugins which decide what to do with the builds’ results.  Out of the box, Continuum comes with the ability to email and/or IM your build results in several ways.  What I needed was a notifier that would send the testng-results.xml file generated by Maven’s surefire testing plugin via a multi-part HTTP POST request to our reporting app.  Sounded simple enough.

Use the Source Luke

A few quick Google searches taught me a couple things: 1) a number of people have wanted to to do exactly what I needed, and 2) there didn’t seem to be any good end-to-end documentation on how to do it.  First step, download the source and get it to compile.  Next, according to the directions on the main site and the user wiki, was a simple mvn install.

First Build – Fail

Unfortunately, the continuum-release module’s tests fail.  I am still looking into why the release module tries to do a SVN commit during a install of the main project and not a deploy, but for the time being, it fails.  In order to get past the release module’s issues (the other modules install just fine and pass their tests) I sinned and added a -Dmaven.test.skip=true to the build and continuum-release installed like a champ.

Second Build – I forgot

Boom!  Not so fast.  OutOfMemoryError from maven while building the web module.  Setting MAVEN_OPTS to increase the max heap memory Maven has fixed the problem.

Third Build – Fell off the log

Boom! Again.   java.lang.NoClassDefFoundError on Commons Logging coming from the JSPC plugin (precompiling JSPS).  It turns out that plugins live in the same classloader as Maven itself and the JSPC plugin requires commons logging.  It also turns out that in the latest version of Maven (2.2.0) the internal dependencies changed and the version JSPC is no longer included in Maven’s “uber”  .jar.  Fix?  Dropped 1.1.1 commons logging three .jars into Maven’s lib folder.  Fixed.

Fourth Build – Houston, We Have Compilation

Finally, everything compiled and installed without problems.  Next up, writing a dummy notifier and getting Continuum to use it.

Tagged with: , ,