Differences between <dependencies> nodes and <dependencyManagement> nodes in Maven

1.dependencyManagement Application Scenarios

Maven uses the Dependencymanagement element to provide a way to manage dependent version numbers, often seeing dependencymanagement elements in an organization or in the top-most pom of a project, in Pom.xml The use of the dependencymanagement element in all sub-projects makes it possible to reference a dependency without explicitly listing the version number . Maven walks up the parent-child hierarchy until a project with the dependencymanagement element is found, and then it uses the version number specified in the dependencymanagement element.

The way in which the dependency management element is indicated in the POM maven combines project inheritance to manage dependencies, the benefit of which is that if more than one subproject references the same version of a dependency, ensure that the dependencies and versions of the individual projects are applied consistently, To ensure that the same results are tested and published, so you should define common dependencies in the top-level pom. You can also avoid declaring a version number in each sub-project that you use, so that when you want to upgrade or switch to another version, you only need to update it in the top-level parent container, without the modification of one sub-item, and if a subproject requires another version, You only need to declare version in Dependencies .

The difference between 2.dependencyManagement and dependencies

dependencies, even if the dependency is not written in a subproject, the child project will still inherit the dependency from the parent project. dependencymanagement is simply declaring dependencies and not implementing them, so the subproject needs to explicitly declare the dependencies that need to be used. If the dependency is not written in a subproject, the dependency is not inherited from the parent project in the subproject, and the item is inherited from the parent project only if the dependency is written in the subproject and no specific version is specified, and both version and scope are read from the parent POM.

3. Use of variables in Pom.xml (easy to maintain)

An explanation of the problem

The syntax for adding dependencies in Pom.xml is as follows

<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>1.2.6</version>
</dependency>

<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-aop</artifactId>
<version>1.2.6</version>
</dependency>

The above is true, but there is a problem, in the spring dependency, we need to refer to a series of versions of spring, such as version 1.2.6, each write is not conducive to maintenance.

Ii. Solutions

Define the properties tab in Pom.xml

<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<spring.version>1.2.6</spring.version>
<developer.organization>xxx</developer.organization>
</properties>

The above content has been changed into

<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>${spring.version}</version>
</dependency>

<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-aop</artifactId>
<version>${spring.version}</version>
</dependency>
Maintenance only needs to modify the properties tag , very clear.

This article is from "Skywalker, in the Cloud" blog, please be sure to keep this source http://tianxingzhe.blog.51cto.com/3390077/1643709

Differences between <dependencies> nodes and <dependencyManagement> nodes in Maven