Maven dependencies

1. What is dependency?

      For example, if you are a man, you want to have children, blah blah blah... How does a man give birth to a child, so you have to rely on your wife, but not necessarily, you can also rely on other girls.

The same is true in our usual project development. You need to rely on some things to achieve the corresponding functions, but the corresponding functions may also rely on other things to achieve, such as database operations, you can rely on hibernate, but you can also use mybatis to do it.

This is the so-called dependency.

In the past, we needed to manually find the jar package of hibernate or mybatis. When the system throws an exception, we still don’t know where to report the error. After thinking about it, we realized that the corresponding jar package was not imported. Here we can see the benefits of maven. It is a warehouse. There are various packages in the warehouse. Just rely on pom.xml for whatever you want. Even if there are no packages in the warehouse, you can put Throw it in the warehouse and rely on it when you want to use it.

2. Dependency transitive scope

2.1.1 Depending on the Jar package, you need to set different delivery methods for it, that is, the delivery range. Dependency transitive scope in Maven is set in the <scope> tag. There are 6 types of values:

(1)   compile

The scope in which the Class 1 Jar package should be set. is the default value. It will pass the dependency down.

(2)   test

The scope in which the Class 2 Jar package should be set. It does not pass this dependency down.

(3)   provided

The scope in which the Class 3 Jar package should be set. It does not pass this dependency down.

(4)   runtime

The scope in which the class 4 Jar package should be set. It will pass the dependency down.

(5)   system

Do not look for the specified dependencies from the local repository, but from the <systemPath> path.

3. Dependency classification

A. Direct dependence

       Project A needs to use the architecture of other project B, so project A directly depends on project B

B. Indirect dependence

        Project B depends on A, C depends on B, then C indirectly depends on A

C. Dependent transitivity

        Maven's dependencies are transitive, such as A->B, B->C, then A indirectly depends on C, which is the transitivity of dependencies, where A is the first direct dependency for B, and B is the first for C. Two direct dependencies, C is A's transitive dependencies.

D. Optional dependencies and excluded dependencies

        Transitive dependencies will implicitly introduce a lot of dependencies into the project, which greatly simplifies the management of project dependencies, but sometimes this feature can also cause problems, it may introduce unwanted jar packages into the project Among them, the project structure becomes more complex. Or you want to replace the default dependency with the jar package you want, then you need to use dependency exclusion.


In the example, the spring-core package depends on the commons-logging package. We use the exclusions element to declare exclusion dependencies. Exclusions can contain one or more exclusion sub-elements, so one or more transitive dependencies can be excluded. It should be noted that when declaring exclusions, only groupId and artifactId are required, and version elements are not required, because only groupId and artifactId are required to uniquely locate a dependency in the dependency graph. In other words, in the dependencies parsed by Maven, it is impossible to have two dependencies with the same groupId and artifactId but different versions.


E. Dependency Conflict (Mediation)

Let's think about such a problem. If A->B->C->X(1.0), A->DX(2.0), that is, A indirectly depends on X, we can see that there are two paths that depend on X, then Which version of X will maven choose? Maven has its own set of rules. Let's explain some rules of Maven's transitive dependencies and how to eliminate dependency conflicts.

Maven has the following rules for transitive dependencies:

        1) The shortest path principle: If A has two identical jar packages in the dependency path, then the package with the shortest path is selected, and the one with the closest path is preferred, and X(2.0) will be selected above.

         2) The first declaration priority principle: If A has two identical jar packages in the dependency path, and the path length is also the same, then the dependency written in the front takes precedence. For example: A->B->F(1.0), A->C->F(2.0), F(1.0) will be selected.

           3) Optional dependencies will not be passed, such as A->B, B->C, B->D, A directly depends on B, B is optional on C and D, then C will not be introduced in A and D. Optional dependencies are configured through the optional element, and true means optional. If you want to use C or D in the A project, you need to explicitly declare the C or D dependencies.


F. Unified management of version numbers

G. Aggregation

 In Maven, we may have to do multiple tests, but do it one by one, which will be very troublesome. For simplicity and convenience, we aggregate all the test packages into one package, and we can use this test to perform all the tests. The test of the test, this process is aggregation. Looking at this aggregation at the current rookie level, the main function is to facilitate Test!

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=325985719&siteId=291194637