Configuring Maven to Use a Local Library Folder

The official "Maven Way" of dependency management is to use Maven Central and local repository specified in the settings.xml file (which usually points to $HOME/.m2/repository. While it works great for projects that rely on a large number of open source libraries and satisfies 95% of dependency management needs in those projects, there is that 5% of the time when a jar is not sourced from a Maven project. One example is a jar using JNI so is only available for certain OS platforms. How do we integrate this jar into Maven dependency management? If you search the web for hints, you may be led to believe that you either have to bend to the Maven Way or to use the systemPath. But the Maven Way will force you to maintain a local repository for a trival library. The systemPath on the other hand does not work naturally with packaging. Developers will most likely ask "Can I check in this library to my (your_favorite_VCS) with my project and still have Maven use it in a way just like any other dependency?" The answer is YES. Just follow the steps below:

1. Create a directory under your project, say "lib".

2. Use Maven to install your jar to the lib directory.
mvn install:install-file -Dfile=path_to_mylib.jar -DgroupId=com.mylib -DartifactId=mylib -Dversion=1.0 -Dpackaging=jar -DlocalRepositoryPath=path_to_my_project/lib

3. Setup your POM like this.

  <repositories>
     <repository>
         <!-- DO NOT set id to "local" because it is reserved by Maven -->
         <id>lib</id>
         <url>file://${project.basedir}/lib</url>
     </repository>
  </repositories>
  <dependencies>
    <dependency>
        <groupId>com.mylib</groupId>
        <artifactId>mylib</artifactId>
        <version>1.0</version>
    </dependency>
  </dependencies>

Now you can check in/out mylib.jar just like any other file in your project and Maven will manage the dependency on mylib.jar just like any other dependency artifact. Perfect harmony. :-)

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

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.