maven dependency version arbitration

maven dependency base

A simple dependency

<dependency>
<groupId>com.alibaba.share</groupId>
<artifactId>test</artifactId>
<version>1.4</version>
</dependency>

依赖库命名规则：
${groupId.part1}/${groupId.part2}/${version}
例：com/alibaba/share/1.4
 
依赖库文件命名规则：
${artifactId}-${version}-${classifier}.${type}
例：test-1.4-source.jar

Note: classfier is the classifier, most of the time it is not used, but it is necessary to write, for example:
TestNG mandatory requires you to provide a classifier to distinguish jdk14 and jdk15

<dependency>  
   <groupId>org.testng</groupId>  
   <artifactId>testng</artifactId>  
   <version>5.7</version>  
   <classifier>jdk15</classifier>  
</dependency>

maven dependency scope

<dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8.1</version>
      <scope>test</scope>
 </dependency>

The above scope is the agreed dependent scope.

• compile: the default value, always available, and will be packaged in the end
• provided: Available during compilation, will not be transitively dependent, and will not be packaged. Example: Depend on a jar package provided in the web container, and the dependency needs to be added when compiling (the web container has not yet intervened), and it is provided by the web container when running.
• test: available when executing unit tests, will not be packaged, and will not be transitively dependent
• runtime: required for running and testing, but not required for compiling
• system: Not recommended
• maven dependency management

Avoid dependency version conflicts in different submodules

Configure dependencies in the main pom

<dependencyManagement>  
    <dependencies>  
     <dependency>  
       <groupId>mysql</groupId>  
       <artifactId>mysql-connector-java</artifactId>  
      <version>5.1.2</version>  
     </dependency>  
      ...  
   <dependencies>  
</dependencyManagement>

Add dependency in sub pom

<dependencies>  
   <dependency>  
    <groupId>mysql</groupId>  
    <artifactId>mysql-connector-java</artifactId>  
   </dependency>  
</dependencies>

DependencyManagement does not actually introduce any dependencies, it will only be added to the sub-pom. After being configured in the parent pom, the child module can automatically inherit the corresponding parent module dependency configuration by simply using the simple groupId and artifactId. If the version in the sub-pom is defined, it will override the one in the management.

Optional dependencies

Add non-transitive dependencies:
add dependencies to a project:

<dependency>
      <groupId>mysql</groupId>
      <artifactId>mysql-connector-java</artifactId>
      <version>1.5</version>
      <optional>true</optional>
    </dependency>

In another project, it depends on the previous project, but if you need to use the mysql dependency, you still need to add it.

Dependent version boundary

Required dependency version >=3.8 and <4.0

<version>[3.8,4.0)</version>

Required dependency version<=3.8.1

<version>[,3.8.1]</version>

The requirement must be version 3.8.1. If it is not, the build will fail, prompting a version conflict. The original wording 3.8.1 means that all versions are fine, but 3.8.1 is best

l<version>[3.8.1]</version>

Eliminate dependencies

Depend on project-a but exclude the dependency on project-b introduced in project-a

<dependency>
  <groupId>org.sonatype.mavenbook</groupId>
  <artifactId>project-a</artifactId>
  <version>1.0</version>
  <exclusions>
    <exclusion>
      <groupId>org.sonatype.mavenbook</groupId>
      <artifactId>project-b</artifactId>
    </exclusion>
  </exclusions>
</dependency>

Replace dependency

Just use the exclusion in the previous step, and then add the dependency to be replaced. There is no special sign to mark that this is replaced.

Version conflict arbitration

Version arbitration rules (tested and verified on maven 2.2.1 version)

• Arbitrate (overwrite) according to the DependencyManager version statement of the project's general POM, but without warning.
• If there is no arbitration statement, the version will be determined according to the shortest path of dependence.
• If the path is the same, the version with strict interval limitation takes precedence.
• If the path is the same and there is no version interval, the preconceived principle shall be followed.