Home > Maven3 > Maven best practices

Maven best practices

Although Maven offers a “convention over configuration” solution, there is still more then enough configuration necessary to cause some serious headache.  In this post I will share some best practices with you that will ease maintenance of your POM files.

  1. Don’t use deprecated references like ${artifactId} or ${pom.artifactId}. Use the new ${project.artifactId} syntax. Note that this syntax follows the XML document structure, which makes it easy to remember and predict the value that the reference will result in.
  2. Try to avoid using inherited properties. Developers can easily forget that a certain property is used by a child POM and change the value breaking the build in an unexpected place. Secondly, its quite annoying not to be able to easily lookup a property without having to find and examine the parent POM.
  3. Use the dependencymanagement section of the parent pom to define all dependency versions, but do not set a scope here so that all dependencies have scope compile by default.
  4. Use properties to define the dependency versions. This way you can get an overview of all versions being used without having to scroll through multiple pages of dependency sections.
  5. Use the pluginmanagement section of the parent pom to define versions for *all* plugins that your build uses, even standard maven plugins like maven-compile-plugin and maven-source-plugin. This way your build will not suddenly behave differently when a new version of a plugin is released.
  6. When using a parent POM that is not located in the directory directly above the current POM define an empty relativePath element in your parent section.
  7. Use the dependency plugin to check your project for both unnecessary dependencies and undeclared-but-used-none-the-less dependencies. The goal is called ‘analyze’, so run the following command on the console: “mvn dependency:analyze”
  8. Make sure the pom files contain all the repository references needed to download all dependencies. If you want to use a local repository instead of downloadin strait from the internet then use the maven settings file to define mirrors for the individual repositories that are defined in the poms.
  9. If you use Nexus, then do not create repository groups containing both hosted and proxied repositories. This will dramaticly reduce the responsiveness because Nexus will check the remote locations of the proxied repositories even if a hosted repository contains the requested artifact.

Make sure you read the best practices from Sonatype as well.

Categories: Maven3 Tags: ,
  1. August 20, 2011 at 4:47 pm

    I wrote up a list of some additional maven best practices here.

  2. June 25, 2012 at 1:47 am

    Regarding #3: Why shouldn’t I set the scope in the dependencyManagement of the parent POM? JUnit should have test scope, my database drivers should have runtime scope etc. — I don’t understand why setting sensible defaults in the parent POM should be a bad thing?

    • motlin
      June 26, 2012 at 3:20 am

      There are a few reasons why the scope would vary by module. If you have a test utility module for example, it would depend on junit in compile scope, not test. It’s easier to read the dependencies if you assume the absence of a scope means compile.

  1. August 20, 2011 at 4:25 pm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: