Now, our Maven project knows what libraries it'll need. We're nearly ready to build. There's just two things we need to tell Maven; firstly that we need to build the source code as Java 1.5 and a way to run it. This goes in the build section.

 <build>
  <finalName>todotasks</finalName>

First thing, in the build section is the final name we want on the built code. Then we define settings for plugins we want to use. Plugins are Maven's way of extending itself. You don't have to install them, just use them; Maven will retrieve them from it's own repository. The first plugin we set up is the maven-compiler-plugin. We just need to tell it it's compiling for Java 1.5 by setting two configuration properties, source and target;

  <plugins>
            <plugin>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>2.0</version>
    <configuration>
     <source>1.5</source>
     <target>1.5</target>
    </configuration>
   </plugin>

Finally, we are going to use a plugin called Cargo, which ships our built web application over to a container that can run it.

   <plugin>
    <groupId>org.codehaus.cargo</groupId>
    <artifactId>cargo-maven2-plugin</artifactId>
      </plugin>
     </plugins>
    </build>
    </project>

Now we are ready to build our project. Recall that Maven's aim is to install our artifact in the repository, so if we ask it to do that, it will go through all the required steps.

    $ mvn install
    …

There will now be much downloading by Maven as it pulls all the plugins and needed artifacts down from the central repositories. But, there is one artifact that we know is missing, the DWR artifact. Maven will eventually error out with this remarkably informative error message;

    [INFO] ---------------------------------------------------------------
    [ERROR] BUILD ERROR
    [INFO] ---------------------------------------------------------------
    [INFO] Failed to resolve artifact.

    Missing:
    ----------
    1) dwr:dwr:jar:2.0M3

      Try downloading the file manually from the project web site.

      Then, install it using the command:
          mvn install:install-file -DgroupId=dwr -DartifactId=dwr \
              -Dversion=2.0M3 -Dpackaging=jar -Dfile=/path/to/file

      Path to dependency:
            1) uk.builder:todotasks:war:2.0-SNAPSHOT
            2) dwr:dwr:jar:2.0M3

    ----------
    1 required artifact is missing.
    …

So we need to download DWR2.0M3 and install it into the repository; DWR2.0M3 isn't up on the main DWR site, you can visit Java.net and download the dwr.jar file there. Then run the command Maven has suggested, obviously substituting in the path to dwr.jar. We can now try running the install again.

$ mvn install
    …

And again there will be some more downloading, compiling of code, unit tests run, web app assembled, war file built from it and the resulting war file installed into the local Maven repository. The results of all this work are in the newly created target directory. Of course, we'd like to run the application now. This is where the cargo plugin comes in. By default, cargo will download and set up and embedded Jetty 5.x web server and run the main war file. To do this, we invoke the start goal of cargo;

    $ mvn cargo:start

Again there will be downloading of the required artifacts, eventually ending with:

    [INFO] [beddedLocalContainer] Jetty 5.x Embedded started on port [8080]
    [INFO] Press Ctrl-C to stop the container...

Open your web browser and go to http://localhost:8080/todotasks/ and you'll find the todotasks web application running.

We've not actually written that much pom.xml file but we already have a build process which takes us through the basic life-cycle. If you look in the target directory, you'll also find a surefire-reports directory with reports on all the run unit tests. This isn't the only thing you can generate; try the Maven site goal like so:

$ mvn site

This generates up a template web site based on the project, stored in target/site. If you open your browser and view the index.html in there you'll see what, if you've looked at many Apache projects, appears to be a familiar layout. In our case, not many pages are populated, apart from the dependencies page, but it is a good indication of the kinds of processes that Maven can help manage.

What's changed in the code?

As we've moved to being a pure web application, there's been a considerable stripdown of the code. Gone are the Swing UI classes, the Main.java and Controller.java. Now, removing those leaves the question of how does the Tasks object come into existence. The TasksFactory now has an added method;

private static Tasks currentTasks;

    public static Tasks getTasks()
    {
        if(currentTasks==null)
        {
            try {
                currentTasks=createTasks(TasksType.JDBM);
            } catch (IOException ex) {
                ex.printStackTrace();
            }
        }
        return currentTasks;
    }

This manages a static instance of a JDBM based Tasks instance. Whenever a class wants a reference to Tasks, it'll call this method instead and Tasks will be created on demand.

Since writing the DWR code, DWR has moved on from milestone 2 to milestone 3, and in the process, they've made the sending of JavaScript code a lot easier, but this does break our example code.

In M3, there is a new class, the ScriptBuffer, into which you can build your script. The ScriptBuffer has two important methods, appendScript and appendData. To add some script text to the buffer, you just use appendScript() with a string parameter;

sb.appendScript("remoteTaskChanged(")

To add an object to that script, you call appendData() with that object:

sb.appendData(tasksevent.taskId)

Of course, you still need make the JavaScript complete, so following the two above lines, we'd need:

sb.appendScript(");"); 

to close the functions parentheses and end the line. Now, one thing worth knowing is that these ScriptBuffer methods return the ScriptBuffer itself allowing you to chain method calls like so:

sb.appendScript("remoteTaskChanged(").appendData(tasksevent.taskId).appendScript(");");

We've also modified the JavaScript client code to get rid of the "If something has changed, reload everything" code and replace it with more intelligent updating of the HTML table, removing rows on deletion, inserting rows as needed and minimising changes generated from when a single task changes. There's lots of changes which we've added extensive comments to for those of you interested.

You can download the source code for this tutorial.

Further reading

We've only skimmed through using Maven here. We've relied heavily on Maven's default behaviours, which come from its "Super POM" file from which all POM files inherit, and the defaults of plugins. Because we were migrating an existing application, we didn't get to use Maven's archetype mechanism, which generates up new templated artifact directories, complete with POM file. To learn more about Maven, start with the Maven web site as your definitive reference. An excellent quick start book is the free PDF ebook Better Builds With Maven from Mergere. You have to register but it's worth it. Maven changes the way you develop and build Java code for the better.

DJ Walker-Morgan is a consulting developer, specialising in Java and user-to-user messaging and conferencing.