Maven Best Practices

TL;DR

Love or hate it… he will stay for a moment.
So let’s apply the best practices to our poms and maven builds.

Make the build reproducible
  - Always specify a version for Maven2 plugins
  - Minimize number of SNASPHOT dependencies
  - Use dependency management section
  - Beware of relocation in maven repo
  - After a dependency modification, double check the produced artifacts
Use and abuse of modules
  - more “technical/layered”
  - more business oriented
Make the build maintainable
  - Prefer default directory layout
  - Avoid duplication by moving common tags to parent pom
  - Always specify a version of dependencies in a parent pom
  - Use Properties Liberally
  - Minimize the number of Profiles
Make the build portable
  - Don’t commit eclipse and maven artifacts
  - Don't modify pom/artifactsin your "enterprise" repository

Make the build reproducible

Always specify a version for Maven2 plugins

Wrong way

<plugin>
 <groupid>org.apache.maven.plugins</groupid>
 <artifactid>maven-surefire-plugin</artifactid>
</plugin>

Correct way

<plugin>
 <groupid>org.apache.maven.plugins</groupid>
 <artifactid>maven-surefire-plugin</artifactid>
 <version>2.3</version>
 </plugin>

This matters because if you leave out the version, maven2 defaults to LATEST  available.

So this can mean that

  • the result of the plugin can become unpredictable if the implementation of the plugin has changed (new/removed feature, …)
  • your project unknowingly became automatic beta testers for third party plugins if the latest version is a SNAPSHOT

Newer version fo m2clipse will this show as warnings in the console. See also the maven enforcer plugin

Minimize number of SNASPHOT dependencies

It’s strictly unrecommended to use SNAPSHOT version in your project dependencies since it’s never guaranteed that a SNAPSHOT version is available in any repository. This can lead to well-know build errors due to missing dependencies . So for projects that don’t belong to ‘you’… it’s preferable to use a real version.

how to detect if you have a snapshot version

Use dependency management section

Transitive dependencies is great feature… but in the end you want to be sure of the version you are using and shipping to production

Dependency Management allows to consolidate and centralize the management of dependency versions without adding dependencies which are inherited by all children. This is especially useful when you have a set of projects (i.e. more than one) that inherits a common parent.

Another extremely important use case of dependencyManagement is the control of versions of artifacts used in transitive dependencies. This is hard to explain without an example. Luckily, this is illustrated in the documentation.

    
    <dependencyManagement>
        <dependencies>
                 ...

Beware of relocation in maven repo

Relocating an artifact is changing the “maven id” (groupId:artifactId) of a project.

xstream:xstream
com.thoughtworks.xstream:xstream

One common pitfall in maven relocation is having double jars even with correct usages of dependencyManagement.
Use the m2clipse and his dependency hierarchy views, to detect and exclude the undesired artifacts.

After a dependency modification, double check the produced artifacts

A good habit is to double check your war/ear produced after the addition of a new dependency or the upgrade of an existing one.
2 greats to tools to help you in this

Use and abuse of modules

the modules can be more “technical”

<modules>
  <module>mymodule_api</module> <!-- service interface, value objects, exception -->
  <module>mymodule_impl</module> <!-- service & dao implementation -->
  <module>mymodule_web</module> <!-- web components, controllers, templates.. -->
</modules>

or

more business oriented

<modules>
   <module>contract_modules</module>
   <module>finance_modules</module>
   <module>time_modules</module>
   <module>agenda_modules</module>
</modules>
 

Make the build maintainable

 

Prefer default directory layout

this will make the plugin configuration more easy :

src/main/java         Application/Library sources
src/main/resources    Application/Library resources
src/main/webapp       Web application sources (for war packaging)
src/test/java         Test sources
src/test/resources    Test resources

Avoid duplication by moving common tags to parent pom

Do you really want to say that you compile for 1.5 jdk in all your projects ?

    
    <!-- Use Java 1.5 -->
    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
       <artifactId>maven-compiler-plugin</artifactId>
       <version>2.3.1</version>
        <configuration>
            <fork>${javacFork}</fork>
            <executable>${javacExecutable}</executable>
            <verbose>${javacVerbose}</verbose>
            <compilerVersion>${jdk.version}</compilerVersion>
             <source>${jdk.version}</source>
            <target>${jdk.version}</target>
        </configuration>
    </plugin>

move this in a parent pom !

for example, in

  corporate_base_pom  ->  app_basecom  ->       app_module1         -> app_sub_modules

    jdk 1.5                    technical                application                     
 enterprise repo             dependencies               dependencies
                             (spring,...)               (app_module2,app_module3,..)

Always specify a version of dependencies in a parent pom

prefer a central place for version definition.
Don’t specify version in a specific sub-modules

Use Properties Liberally

Grouping Dependencies with properties… to avoid copy/pasting the version everywhere.
and help upgrading easily to 3.0.5.RELEASE 😉
And move this to a parent pom : cfr Avoid duplication move to parent pom

<properties>
    <spring.version>3.0.0.RELEASE</spring.version>
</properties>

<dependencies>
    <dependency>
        <groupId>org.springframework</groupId>
         <artifactId>spring-webmvc</artifactId>
        <version>${spring.version}</version>
    </dependency>
    <dependency>
        <groupId>org.springframework</groupId>
         <artifactId>spring-tx</artifactId>
        <version>${spring.version}</version>
    </dependency>
    <dependency>
        <groupId>org.springframework</groupId>
         <artifactId>spring-jdbc</artifactId>
        <version>${spring.version}</version>
    </dependency>
</dependencies>

Minimize the number of Profiles

Profiles can help a lot… but will inevitability complexify the process.
So don’t use profiles if for example adding a new project with and assembly will do the trick. best practices

  • The build must pass when no profile has been activated
  • Use profiles to adapt to build-time context, not run-time context, and not (with rare exceptions) to produce alternative versions of your artifact

Remark: The support for profiles outside of the POM or the settings.xml has been removed in Maven 3.x.

Make the build portable

don’t commit eclipse and maven artifacts

to make the checkout easier… avoid commiting the following files and directory

.project
.classpath
.settings
.wtpmodules
target

these files are often :

  • referencing local settings like JRE name/path/…
  • specific to a version of plugins (wtp,…)

so let m2clipse handle this and maintain/generate the .project, .classpath,…

see svnignore/cvs ignore

Don’t modify pom/artifacts in your “enterprise” repository

It’s always tempting to fix a pom or a jar in the central repository… don’t do this.
Identify it a special version in your repo ‘artefact-1.0.5.corporatepath’ or manage the correct exclusions.
see log4j example

Advertisements

  1. #1 by Mathew Bukowicz on May 18, 2012 - 9:57 am

    Nice post. Thanks for sharing.

  2. #2 by javageek on May 25, 2012 - 2:12 pm

    org.apache.maven.plugins
    maven-compiler-plugin
    2.3.1

    ${javacFork}
    ${javacExecutable}
    ${javacVerbose}
    1.5
    1.5
    1.5

    you could store the jdk version (1.5) also in a maven property

    org.apache.maven.plugins
    maven-compiler-plugin
    2.3.1

    ${javacFork}
    ${javacExecutable}
    ${javacVerbose}
    ${jdk.version}
    ${jdk.version}
    ${jdk.version}

  3. #4 by bunkertor on June 19, 2012 - 4:41 pm

    Reblogged this on bunkertor.

  4. #5 by mestachs on June 24, 2012 - 3:05 pm

    another point use and abuse of modules and Huge overhead in repository snapshot artifact lookups : http://mindthegab.com/2010/10/21/boost-your-maven-build-with-best-practices/

  5. #6 by bkimminich on December 23, 2013 - 8:37 am

    Reblogged this on Björn Kimminich's Blog.

  6. #7 by iamsocurious on June 26, 2015 - 2:24 pm

    Reblogged this on Iamsocurious.

  7. #8 by Shivan Koendan Panday on August 27, 2015 - 2:33 pm

    Don’t forget to specify encoding before the first commit.
    Use the enforcer pluging

  1. RSS Digest: Week Ending 18-May-2012 | Zahid Qureshi
  2. Blog bookmarks 05/19/2012 « My Diigo bookmarks
  3. JavaPins
  4. Mejores prácticas con Maven | El Blog de rubensa

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s

%d bloggers like this: