In-depth discussion: Bill of Materials BOM in Maven

In-depth discussion: Bill of Materials in Maven

2019 Nian 6 Yue 4 Ri A Youshen · Pula Sha (Ayush Prashar) the Java , project management bill of materials , dependency management , Maven , Maven plugin

Reading time: 3 minutes

Recently, when using Spring WebFlux, I met a very useful BOM concept, also known as BOM table (Bill of Materials), this concept is actually not limited to Spring. BOM is one of several ways Spring helps us forget about transitive dependencies and focus our attention on project requirements.

Therefore, when we usually create a large project with dozens or hundreds of dependencies, it is very likely that transitive dependencies are common items used within the project. Therefore, suppose we have a dependency called "common-3.0.0.RELEASE", which is used by the artifacts of logging, and the version of "common-2.9.0.Release" used by the test framework. In this case, there will be conflicts. We need to make sure to get a usable version so that the two artifacts can work together.

Maven has a way to solve this problem for us. It uses the dependency mediation (dependency mediation). It uses a concept dependency path The package with the shortest project path will be selected by other packages. Assuming that in our example, the dependency chain is similar to log4j -> commons-2.9.0.Release and JUnit -> unit-tests -> common.3.0.0., Maven chooses commons 2.9 because its dependency path is away from the current POM Shorter.

But when we can get it right, why rely on some external method? By specifying it in the POM, we can always use the version we want or even transition. Of course, this will confuse our POM, because we may have a lot to write. We can let dependency management (dependency management) to control, maybe it is a better way.

Bill of materials

Maven lets us define versions of dependencies or transitive dependencies in a separate pom. In this pom, we declare the version and scope of dependencies. Therefore, we can focus on all the dependency details.

Let's create a sample bill of materials pom file.

It can be seen that the bill of materials is a completely normal POM file, and we can include dependency information in it.

How to use it?

Now we understand that the BOM is a file that contains all the information about any dependency version of our project. The next step is to include this file in our original POM.

One way to do this is Spring's way, inheriting it like the parent project. All we need to do is provide the parent information in the parent tag.

Although this is how Spring works, we cannot inherit from multiple parent poms. Therefore, if you wish to inherit from multiple, we will pass the credentials in the dependencies.

priority

Therefore, there are multiple ways to determine the version, which means there is a priority order.

1. The version provided in the direct declaration in the POM has the highest priority.
2. The version provided in the parent pom has second priority.
3. The imported pom version ranked third
4. Finally, the version we got from dependency mediation

If a conflict occurs when multiple poms are inherited, the dependencies declared earlier in order take precedence.

Therefore, now you can understand why the magical automatic configuration is possible in the Spring pom, what the BOM is, and what to do if a specified version is required.

Reference:

Maven Doc

Maven foundation