Tuesday, July 26, 2011

Taking Control of Maven Multi-Module Project

Maven has come a long way in supporting an assembly line style of software development. It is common for a non-trivial project to have multiple inter-dependent modules, external system dependencies and geographically distributed teams. This blog provides a few tips on some standard Maven tools to help developers tackle this complexity.

Building Single Module in a Multi-Module Project

When multiple teams work on a large multi-module project, it is often desirable to build just one module instead of the world. But Maven doesn’t make this obvious. For example, if the sub-module-A depends on the sub-module-B, building sub-module A was not even possible in 2009 without “mvn install” sub-module-B in the repository first! Fortunately, Maven has evolved. This is where the advanced reactor options come in. To build a single module, run this command at the parent level:

mvn –projects sub-module-A –also-make clean test
The “—also-make” option tells Maven to automatically build all modules that sub-module-A depends on before building A. No “mvn install” of dependent modules is needed. This ensures a clean build for single-module building.

Build Profile
Developers often want to set up repository locations and test environments in physical proximity because of cost and regulation differences between geographical regions. Build profiles allow developers to tailor their projects to diverse build environments without interfering with each other.

Command-Line Settings.xml
Secure environments often require access credentials. For security reasons, Maven requires these credentials to be stored in settings.xml. This often causes more problems than it solves. One workaround is to store different versions of settings.xml files along with the project files in the source repository. Then when a project is checked out, the “-s” command line option can be used to specify which settings.xml file to use for running Maven.

mvn –s ${CHECKOUT_DIR}/setting/settings.xml clean test

Friday, July 15, 2011

Automating Remote File Copy

When you need to move files around inside a secure environment, rcp and ftp scripts can be a real time saver.


The easiest way to copy a file from any machine to a destination host without using password is to use the .rhosts file. This file should reside in a user's home directory. For example, for user "foo" on host "dest", this file will contain this line:

+ foo

Now you can remote copy files from anywhere to host "dest" without typing a password:

rcp file foo@dest:/home/foo/.

Scripting ftp

The trick to script ftp command is to turn off the interactive mode by using the "-n" option. This allows you to put password in the script. Here is an example to ftp a file from foo's home directory:

ftp -n dest  << whatever
user foo foopass
get file

These two little commands can do wonders in a heterogeneous but secure environment with mixed Linux/Unix/Windows boxes. Use them to your heart's content.

Wednesday, July 13, 2011

Maven Failsafe Plugin Gotcha

I should have known this but it didn't occur to me when integration tests in a Maven project suddently stopped running any test at all. It turned out that the Maven Failsafe Plugin did not have a notion of "compiling test classes" on its own. It is normally not a problem when the plugin is used in a lifecyle. But it falls apart when the failsafe:integration-test goal is executed independently like this:

mvn clean failsafe:integration-test

In this case, the plugin will not run any integration test because not a single class is compiled after clean. The plugin depends on class file naming conventions (such as IT*.class) to run tests. No class file, no test.