BOM stands for "bill of material" and defines an easy way to manage your dependency versions.
The BOM concept depends on the import scope introduced with Maven
2.0.9, that allows you to merge or include the dependencyManagement
of a foreign POM artifact in your POMs dependencyManagement section without
inheriting from it.
<dependency> <groupId>com.coremedia.cms</groupId> <artifactId>core-bom</artifactId> <version>5.4.23</version> <type>pom</type> <scope>import</scope> </dependency>
The inclusion or merge is done before the actual dependency resolution of your project is done. By the time the actual resolution starts Maven does not see any BOM imports but only the merged or included dependencies.
For projects using a framework that provides many artifacts like CoreMedia does, this means, that you can fix the versions for all dependencies that are part of that BOM, by simply declaring one dependency.
Of course there are pitfalls when using BOMs and the import scope, but the
benefits of using BOMs overcome any disadvantages. To prevent you from falling into one of the
pitfalls, the following paragraphs will show you how to use the BOM approach correctly.
Chaining BOMs and artifact procurement
Artifact procurement is a feature that some repository management tools like Nexus or Artifactory offer you to allow your project to use only explicitly configured versions of their dependencies. In addition to the local dependency management in your POM files, artifact procurement is done remotely in your artifact repository. Because of this fact, artifact procurement is much stricter and most commonly only applied in organizations, where securing build infrastructure has the highest priority.
When you chain BOM files, which means that the BOM you import, imports another BOM and so forth, you cannot achieve complete artifact procurement if any POM enforces a different version of a BOM than the version that is used within that chain of its predecessors. This problem stems from the fact that all import scoped dependencies must be resolved in any case, even if your topmost project enforces a different version. Luckily this only affects POM artifacts, you cannot compile against or which have no effect when deployed to the classpath.
BOM import order
Because the import scope is more likely an xinclude on XML basis, ordering of these imports is crucial if the BOMs content is not disjoint, which is most likely the case in presence of chained BOMs.
As a result, it is important to list the BOM imports in reverse order of the BOM import chain.
To make sure your update is correct you should therefore always create the effective POM and
check the resulting dependencyManagement section. To do so execute:
$mvn help:effective-pom -Doutput=effective-pom.xml
 |  |  |
 |