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
  • defining developer, license, organisation in one location

PomParent content :


<!– The Basics –>

<!– build mechanism property –>
<!– Plugin having a custom setting –>
<!– Build Settings –>

<!– More Project Information –>
<name>Apache License, Version 2.0</name>
<comments>A business-friendly OSS license</comments>
<name>Laurent Tardif</name>
<email>Laurent.Tardif at</email>

<!– Environment Settings –>
<!– not inherited –>

Inclusion in other pom :

<!– hint path, not mandatory –>

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.

<!– build mechanism property –>



 3) define common build step in the pom Parent

In the pom parent you can define common build section in order to centralized that.

Now Imaging you have 4 modules, let’s say two standard jar libraries, and two webservices with code generation, and so on….

The build steps are not common to the 4 modules, but in this case you can make 3 pomParent :

1) first one common to every one (with dependencies version, common variables, … )

2) Second one, including first one, and defining build step for jar

3) 3rd one , including first one, and defining , source code generation, and so on for webservices.