This post in the 3rd one of a series on maven3. You can find the information related to the demo project used in example here.

One of the painful thing with all build management system, is the maintenance.

Setting it up at the beginning is ok, but maintaining it over time take time. Ensuring that all tools run on all modules, with same version, that the experiment you made on one module, or on a subset of module do not brake the whole things ….

So, in this post will see some tips to avoid information duplication in order to ease maintenance.

1: use pomParent mechanism to share most of the configuration

The pom parent mechanism is an “inclusion like” mechanism. It’s well defined here.
In the demo project, you have it located in the PomParent directory, and it’s used in all the others pom files.
In the following pomParent I am :

defining common properties (java version, encoding, plugin version) use in all pom files

defining plugin management element for all plugin used in one of the pom, in order to have plugin version centralized in one location

2: use properties to centralize in a common place important informations.

This is the first advise I’ll give. Use properties to put in a common place, informations your need to share.

you can define as many properties you want, and reuse them in any part of the pom file. If you define them in a PomParent, you can reuse them in all pom files. That’s help having easy to maintain project.

Among the practices i liked (but not every one agreed :-), I’m agree also to say that in the example, it’s a bit too much :-), but it’s an exercise … ), is to duplicate variable definition, in order to know where it’s used. That make also my life easier when the value need to be changed locally.

One of the common usage of maven, is to work most of the time connected. Before going deeper, let explain quickly how maven work. when you run the following command to display the project hierarchy :

mvn dependency:tree

It will check on you build repository for new snapshots, or dependencies update to display it. There’s lot of command that will lead to an update of either your project dependencies, or the plug-in used by maven to build your project.

In order to control when you check update or not, you have the –offline to disable all remote access, and the -U as example, to force verification of updates. The maven –help command list all the options possible at Maven level, it’s independent of the content of your pom, or of any setting you defined.

mvn –offline dependency:tree

2: Use several thread to work

By default, maven will use One thread to work. Since maven3, you can use several thread to do the job.

You have 2 options to define the number of threads to use

The first one is by explicitly specifying the number of threads to use (2 in the example)

mvn -T2 compile

The second one is by specifying the number of thread relatively to the number of core you have on the PC (2 thread per core in the example)

mvn -T2C compile

The second option is very interesting on a heterogeneous build farm or in script, where you can adapt you number of thread regarding the number of cores available at run time.

3: Build partially your project

You can also optimise your build time , when running :

mvn compile

Maven will build the list of project/module to build, and will determine a build order. For each module, it will check if building it make sense (if no sources, tests or ressources change, there’s no point to rebuild the project).

Even if the verification is efficient, doing it on large project make no sense when, as a developper, you know where you change stuff, and want to do only a partial build.

As you see, maven will scan for project, construct the ordered list of projects, and will start build at the module or project.

You have several option to control more precisely the resume, let see some :

Options:
-am,–also-make If project list is specified, also build projects required by the list
-amd,–also-make-dependents If project list is specified, also build projects that depend on projects on the list
-B,–batch-mode Run in non-interactive (batch) mode
-fae,–fail-at-end Only fail the build afterwards; allow all non-impacted builds to continue
-ff,–fail-fast Stop at first failure in reactorized builds
-N,–non-recursive Do not recurse into sub-projects
-pl,–projects <arg> Comma-delimited list of specified reactor projects to build instead of all projects.
A project can be specified by [groupId]:artifactId or by its relative path.
-rf,–resume-from <arg> Resume reactor from specified project

Rate this:

I have help a team recently to move to maven 3, and ask for “what’s the standard way to organise a project ?”.

Using Maven, you are encourage to follow convention to organise your library sources, but working at a project level you have more freedom.

When you use Maven since years, yo know there’s some good / bad practices that will make your project easy to maintain or not. Recently, some plug-in maintainer have advise a structure, and I’m pretty align with it.