Coordinate and dependency of Maven details

Look at the simple and complex pom. XML files seem familiar. When I write them myself, I think it is simple, but I think it is complicated when I look at other people's projects. Now let's analyze this pom file together.

Maven coordinates introduce order for various components. Any component must clearly define its own coordinates. MAVEN coordinates include the following elements:

Groupid: Define the actual project to which the current Maven project belongs

Artifactid: This element defines a Maven project or module in the actual project.

Version: This element defines the current version of the maven project.

Packaging: This element defines how Maven projects are packaged.

Classifier: This element is used to help define some ancillary components for building the output.

Note: groupid, artifactid, version, and packaging must be defined. classifier cannot be directly defined, because ancillary components are not directly generated by default by the project, it is generated with the help of an additional plug-in.

Element details:

Detailed description of dependencies element under the root element project:

Dependencies can contain one or more dependency elements to declare one or more project dependencies, including the following elements:

Groupid,Artifactid,Version: The basic coordinates of dependencies. For any dependency, the basic coordinates are the most important. MAVEN finds the required dependencies Based on the coordinates.

Type: Dependent Type

Scope: Scope of dependency

Optional: Indicates whether dependency is optional (see optional dependency)

Exclusions: Used to exclude the pass-through dependency (see the dependency's pass-through)

Detailed description of dependency scope:

MavenCompile the project master codeYou need to use a set of classpath

MavenCompile and execute testsWill use another classpath

MavenActual running projectThen, a set of classpath is used.

The dependency scope is used to control the relationship between dependencies and the three classpath (compile classpath, test classpath, and run classpath ).

Six dependency scopes of Maven:

Compile: The compilation dependency range (default). It is valid for compiling, testing, and running classpath.

Test: Test the dependency scope, which is only valid for the test classpath. Typical Example: JUnit

Provided: The provided dependency scope is valid for compiling and testing classpath, but does not work at runtime. Typical Example: servlet-API

Runtime: The runtime dependency scope is valid for testing and running classpath, but not for compiling the main code. Typical Example: JDBC

System: System dependency Scope

Import: (Maven2.0.9 and later): The scope of the imported dependencies. It does not affect the three actual classpath types.

Scope)	Effective for classpath Compilation	Effective for testing classpath	Effective for the classpath at runtime	Example
Compile	Y	Y	Y	Spring-core
Test		Y		JUnit
Provided	Y	Y		Servlet-API
Runtime		Y	Y	JDBC driver implementation
System	Y	Y		Local, class library files outside Maven Repository

After understanding the basic elements and scope of dependencies, we will find that some default configuration problems often occur in our projects, resulting in compilation and running failure, now, let's learn how to solve these problems. First, we need to understand the portability of dependencies.

Transmission dependency and dependency Scope

To put it simply, most of the problems that occur in projects are due to repeated references, references to dependencies of earlier versions, or changes in their dependencies.

For example, to understand the transmission dependency:

We created a Maven project ----- learndependency, introduced the spring-core dependency, and then opened the spring-core pom. XML finds that spring-core also has its own dependency: commons-logging, and the dependency does not have a declared dependency scope. Therefore, compile is the default dependency, so we can say: commons-logging is also a dependency of learndependency. In this case, we call this dependency a transfer dependency. commons-logging is a transfer dependency of learndependency. With the passed dependency, we can ignore whether the introduced dependency requires other Dependencies and whether redundant dependencies are introduced. MAVEN will parse the direct dependency pom, introduce necessary indirect dependencies into the project.

Let's talk about the transmission dependency.

Assume that a depends on B and B on C. Then we say that a is the first direct dependency on B, B is the second direct dependency on C, and A is the transmission dependency on C.

Because dependency has a dependency scope, how does Maven define the dependency scope for this transfer dependency?

When the range of the second direct dependency is compile, the scope of the passed dependency is consistent with that of the first direct dependency;

When the range of the second direct dependency is test, the dependency will not be passed.

When the range of the second direct dependency is provided, only the dependency of the first dependency is also provided, and the range of the passed dependency is also provided;

When the range of the second direct dependency is runtime, the scope of the transfer dependency is the same as that of the first direct dependency, except for compile. In this case, the transfer dependency range is runtime.

	Compile	Test	Provided	Runtime
Compile	Compile			Runtime
Test	Test			Test
Provided	Provided		Provided	Provided
Runtime	Runtime			Runtime

The first column on the left indicates the first direct dependency range, and the first row indicates the second direct dependency.

After learning about the powerful dependency mechanism of Maven, we began to solve the problem:

FAQ 1: Repeated dependency Introduction

Previously, Maven can effectively solve the problem of repeated dependency introduction, but why do we still have such problems in the project? Let's take a look at how Maven handles repeated introduction issues:

Scenario 1: In the project, we introduced two C dependent on a and B, and a dependent on C, C dependent on D, and B Dependent on D, however, C depends on different versions of D and B Dependent on d at this time:

Project-A---C----D

Project-B---D

That is to say, the current project has introduced the D dependency twice. Then, MAVEN will adopt the first principle:Path closest Principle

Scenario 2: We introduced two dependencies A and B in the project, and both A and B introduced C. However, in this case, the C version on which a depends is different from the C version on which B Depends. How can Maven handle this problem?

At this time, the first principle does not work anymore,

In maven2.0.8 and earlier versions, Maven Versions later than maven2.0.9 have different processing methods for this situation.

Specifically:

In maven2.0.8 and earlier versions, it is uncertain which version of MAVEN will parse the dependency.

InMaven2.0.9In later versions, the second principle is formulated:First speaker preferred

That is to say, it depends on the order of dependency declaration in POM

This problem explains why we often encounter a project that can run normally, and then we add a seemingly unrelated dependency, and then the project has an error, this is what the passed dependency is!

One of the situations that need to be added is the optional dependency.

Why is there an optional dependency? It is because a project has implemented multiple features, but in the object-oriented design, we have a principle: single responsibility principle, that is, to emphasize that there is only one responsibility for a class, instead of combining too many functions, such optional dependencies rarely appear.

FAQ 2: the default dependency introduced-the version of the second direct dependency is too low or the dependency is unstable.

We often encounter this problem during development. We introduced version 1.0 in a second direct dependency, but now we want to use version 2.0. How can we solve this problem?

Introduce a term: exclude dependencies, or replace dependencies.

To exclude dependencies and replace them with the desired dependencies, we need to use <exclusions> and <exclusion>. We can use this element to declare exclusion dependencies, then, declare the dependencies we want. in <exclusions>, you can declare one or more <exclusion> to exclude one or more passed dependencies.

Note: When declaring <exclusion>, you only need to declare the groupid and artifactid to uniquely locate a dependency in the dependency graph.

A -------> B ------ × ---- C (version1.0)

|

|

C (version2.0)

FAQ 3: Solve repeated configurations

We often encounter this situation during development. For example, when using Spring framework, they all come from different modules of the same project. Therefore, these dependent versions are the same, in addition, these versions will be upgraded together in the future. In this case, Maven provides a solution ------ use the properties element to define the maven attribute and then reference it.

Example:

<properties><springframework.version>2.5.6</springframework.version></properties>

At this time, we can use $ {springframework. Version} to replace the specific version number when declaring the dependency.

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

How to optimize dependencies correctly

First, we must understand the maven dependency processing method, and then we can remove unnecessary dependencies and declare necessary dependencies to ensure that only a unique version of each component exists in the dependency.

Run the following command to view the resolved dependencies of the current project:

MVN dependency: List

After Maven parsing, a dependency tree is formed.

You can also run the following command to view the dependency tree of the current project:

MVN dependency: Tree

Use commands to analyze the dependencies of the current project:

MVN dependency: Analyze

Two important parts of the command execution result:

Used undeclared dependencies: Used in the project, but the declared dependency is not displayed.

Unused declared dependencies: indicates that the project is not used, but the declared dependency is displayed.

Note:Dependency: analyze only analyzes the dependencies required to compile the main code and test code. The dependencies required for testing and running cannot be found.

For the best practices in the project, you need to try a lot or read some other people's shares, which will be of great help to the development efficiency, of course, continuous optimization and adjustment in the process of project development is not a problem.

The ancients said: "It is difficult to cover the water ". The speech is like a splash of water. The splash of water cannot be recovered, and the words that have been said cannot be retained. Therefore, you have to think carefully before leaving a sentence. The speech is an art. Even if you speak well, you must worry that you cannot "Wash your face in your nose". If you say this person is good and you offend that person, you cannot speak well enough. If you cannot speak well, neither party will be happy to hear it.