Maven Tutorials-Coordinates and dependencies

One of MAVEN's main functions is to manage project dependencies, and Maven must uniquely identify them in order to be able to parse any one of the Java artifacts automatically, which is the underlying base of dependency management-the coordinates. 1. MAVEN coordinates

MAVEN defines a set of rules for unified management of various Java artifacts: Any Java component in the world can use MAVEN coordinates to uniquely identify it, and a set of MAVEN coordinates is defined by some elements, including: GroupId, Artifactid, Version, packaging, classifier. Take Spring-jdbc dependency as an example, as follows:

<dependency>
  <groupId>org.springframework</groupId>
  <artifactid>spring-jdbc </artifactId>
  <version>4.3.2.RELEASE</version>
</dependency>

Here is a detailed description of each coordinate element:

GroupId: defines the actual project that the current MAVEN project belongs to. Spring
The framework has multiple sub-modules, such as Spring-core, Spring-context, Spring-beans, Spring-test, and so on.

Artifactid: This element defines a MAVEN project (submodule) in the actual project, and the recommended practice is to use the actual project name as the prefix for the Artifactid, and the advantage is that it is easy to find the actual artifacts.

Version : This element defines the current version of the MAVEN project, as in the previous example, the version of SPRING-JDBC is 4.3.2.RELEASE.

Packaging: This element defines how the MAVEN project is packaged. Packaging typically corresponds to the file name extension of the generated artifact. If packaging is a jar, the final file name is Artifactid-version.jar. When packaging is not defined, MAVEN uses the default value jar.

classifier: This element is used to help define some of the subordinate artifacts of the component output. The subordinate component corresponds to the main component, as the main component in the previous example is Spring-jdbc-4.3.2.release.jar, and the project may also generate a spring-jdbc-4.3.2.release-javadoc.jar, Spring-jdbc-4.3.2.release-source.jar Some of these ancillary components.

Of the 5 elements above, groupId, Artifactid, and version must be defined, packaging is optional (the default is the jar), and classifier is not directly defined. 2. Dependent configuration

In large-scale project development, it is inevitable to rely on some external modules, such as spring, SPRINGMVC, OKHttp, JUnit and so on. In the MAVEN project we can declare dependencies in the Pom.xml file, as follows:

<project xmlns= "http://maven.apache.org/POM/4.0.0" xmlns:xsi= "Http://www.w3.org/2001/XMLSchema-instance" xsi: schemalocation= "http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" > < Modelversion>4.0.0</modelversion> <groupId>com.bytebeats</groupId> <artifactid>ngrpc </artifactId> <version>1.0-SNAPSHOT</version> <packaging>jar</packaging> &LT;NAME&G T Ngrpc</name> <url>http://maven.apache.org</url> <dependencies> <!--Netty---&
      Lt;dependency> <groupId>io.netty</groupId> <artifactId>netty-all</artifactId> <version>4.1.6.Final</version> </dependency> <!--log--> <dependency> &lt ;groupid>org.slf4j</groupid> <artifactId>slf4j-api</artifactId> <version>1.7.21< /version> </dependency> <dependenCy> <groupId>ch.qos.logback</groupId> <artifactId>logback-core</artifactId> & lt;version>1.1.7</version> </dependency> <dependency> <groupId>ch.qos.logback< /groupid> <artifactId>logback-classic</artifactId> <version>1.1.7</version> &lt ;/dependency> <!--test--> <dependency> <groupId>junit</groupId> <artifa ctid>junit</artifactid> <version>4.12</version> <scope>test</scope> </
 Dependency> </dependencies> </project>

The root element under project dependencies can contain one or more dependency elements to declare one or more project dependencies. The elements that each dependency can contain are: groupId, Artifactid, Version: The basic coordinates of the dependency, the basic coordinates are the most important for any one dependency, and Maven can find the required dependencies based on the coordinates. Type : the dependent types, corresponding to the packaging defined in the project coordinates. In most cases, the element does not have to be declared, and its default value is jar. Scope : The dependency range, in the above example, JUnit has a dependency of test. Optional: identifies whether the dependency is optional. exclusions: used to exclude transitive dependencies.

Most dependency declarations contain only basic coordinates, but in some special cases, other elements are also critical. 3. Range of Dependencies

Maven needs to use a set of classpath when compiling the project's main code. In the example above, Logback-core is required to compile the project Master code, which is introduced to classpath in a dependent manner. Second, MAVEN uses a different set of classpath when compiling and executing tests. The JUnit in the previous example is a good example, and the file is also introduced to the classpath used by the test in a dependent way, but the scope of the dependency is test. Finally, when you actually run the MAVEN project, a set of classpath is used, and the logback-core in the previous example needs to be in the classpath, and JUnit does not.

The scope of dependency is to control the relationship of dependencies with these three classpath (compile classpath, test classpath, run Classpath), and Maven has the following dependencies:
Compile: Compilation dependency range. If not specified, the dependency scope is used by default. Using this dependency-dependent Maven dependency is valid for compiling, testing, and running three kinds of classpath. The typical example is Logback-core, which needs to be used when compiling, testing, and running.

Test : tests the dependency range. With this dependent Maven dependency, only for test classpath, you will not be able to use this dependency when compiling the main code or running the project. The typical example is JUnit, which is only needed when compiling test code and running test cases.

provided: The range of dependencies has been provided. Use of this dependent MAVEN dependency is valid for test and test classpath, but not valid at run time. The most typical example is SERVLET-API, which requires this dependency when compiling and testing a project, but when the project is run, it is not necessary for Maven to introduce it repeatedly because the container is already available.

Runtime : run-time dependent range. Use of this dependent MAVEN dependency is valid for testing and running classpath, but not when compiling the master code. The typical example is the JDBC driver implementation, the project Master code compilation only requires the JDBC interface provided by the JDK, only need to implement the specific JDBC driver of the above interface when executing the test or running the project.

System : The range of systems dependencies.

Import : imports the dependency range, only in Maven2.0.9 and later.

4. Reliance on delivery

Maven's transitive dependency mechanism
If Maven project A has a compile range of spring-jdbc dependencies, and Spring-jdbc has a compile range of spring-tx, then SPRING-TX becomes the compile range dependency of Project A. Spring-tx is a transitive dependency of project A.

5. Reliance on mediation

The transitive dependency mechanism introduced by MAVEN, on the one hand, greatly simplifies and facilitates the declaration of dependency, on the other hand, in most cases we only need to be concerned about what the direct dependencies of the project are, without regard to the transitive dependencies that these direct dependencies introduce. But sometimes, when transitive dependencies cause problems, we need to know exactly which dependency path the transitive dependency was introduced from.

For example, project A has such a dependency: a->b->c->x (1.0), A->d->x (2.0), X is the transitive dependency of a, but there are two versions of X on two dependent paths, and which x is used by MAVEN parsing. It is obviously wrong to have two versions parsed, because that can cause dependency duplication, so you must choose one.

The first principle of Maven-dependent mediation (Dependency mediation) is that the path is the most recent priority. In this example, X (1.0) has a path length of 3, and X (2.0) has a path of 2, so X (2.0) is parsed for use.

The first principle of relying on mediation does not solve all problems, such as dependency: A->b->y (1.0), A->c->y (2.0), Y (1.0) and Y (2.0) are the same length of the dependent paths, all 2. So who in the end would be parsed to use it. This is not deterministic in Maven 2.0.8 and previous versions, but starting with Maven 2.0.9, to avoid the uncertainty of construction as much as possible, MAVEN defines a second principle that relies on mediation: the first one is preferred. Depending on the length of the dependent path, the order in which the claims are relied on in the Pom file determines who will be parsed, and the first dependency in the order of precedence. In this example, if the declaration of B precedes C, then Y (1.0) is parsed for use.

6. Optional Dependencies

Given such a dependency, Project A relies on Project B, and Project B relies on both Project X and Y,b dependencies on X and Y are optional: a->b,b->x (optional), b->y (optional). Based on the definition of transitive dependency, if all of the 3 dependent scopes are compile, then X, y is the compile range transitive dependency of a. However, since X and y are optional dependencies, dependency will not be passed. In other words, X, Y will not have any effect on a.

Why use the optional dependency feature? It is possible that project B implements two features where the attribute 1 is dependent on X, attribute 2 is dependent on Y, and the two attributes are mutually exclusive and cannot be used by the user at the same time. For example, B is an ORM framework, it supports a variety of databases, including MySQL, Oracle, PostgreSQL, etc., when the component of this toolkit, the two types of database drivers, but when using this toolkit, only rely on a database.

7. Best Practices

After understanding the main functions and principles of Maven's dependency management, the most important thing is to practice it yourself, after all, it's a matter of practice. 1. Exclude Dependencies

Transitive dependencies implicitly introduce a lot of dependencies to a project, which greatly simplifies the management of project dependencies, but sometimes this feature also poses problems. For example, Dubbo relies on SERVLET-API 2.5, and the current project uses SERVLET-API 3.0, as in the following example:

<project> <dependencies> <dependency> <groupId>com.alibaba</groupId>
          <artifactId>dubbo</artifactId> <version>2.5.3</version> <exclusions> <exclusion> <groupId>javax.servlet</groupId> <artifactid>servlet-api </artifactId> </exclusion> <exclusion> <groupid>org.slf4j</gro upid> <artifactId>slf4j-api</artifactId> </exclusion> &LT;EXCLUSION&G
            T
        <groupId>log4j</groupId> <artifactId>log4j</artifactId> </exclusion> </exclusions> </dependency> <dependency> <groupid>javax.servlet</gr
      Oupid> <artifactId>javax.servlet-api</artifactId> <version>3.1.0</version> </dependency> <!--log--> <dependency> <groupId>org.slf4j</groupId> &lt

      ;artifactid>slf4j-api</artifactid> <version>1.7.21</version> </dependency> <dependency> <groupId>ch.qos.logback</groupId> <artifactid>logback-core</artif actid> <version>1.1.7</version> </dependency> <dependency> <grou Pid>ch.qos.logback</groupid> <artifactId>logback-classic</artifactId> <version> 1.1.7</version> </dependency> <!--test--> <dependency> <groupid>j
        Unit</groupid> <artifactId>junit</artifactId> <version>4.12</version> <scope>test</scope> </dependency> </dependencies> </project>

2. Classification Dependency

In peacetime development, we often need to use the spring framework dependencies, which are different modules from the same project, so all of these dependent version numbers are the same, and it is foreseeable that these dependent versions will be upgraded together if the spring framework needs to be upgraded in the future.

<project> <properties> <java.version>1.7</java.version> <springframework.version>4. 3.2.release</springframework.version> <project.build.sourceencoding>utf-8</ Project.build.sourceencoding> </properties> <dependencies> <!--Spring-to &lt ;d ependency> <groupId>org.springframework</groupId> <artifactid>spring-core</a Rtifactid> <version>${springframework.version}</version> </dependency> < Dependency> <groupId>org.springframework</groupId> <artifactid>spring-beans</a Rtifactid> <version>${springframework.version}</version> </dependency> < Dependency> <groupId>org.springframework</groupId> <artifactId>spring-context< /artifactid> <version>${springframework.version}</version> </dependency> <dependency> &LT;GROUPID&GT;ORG.SPRINGF Ramework</groupid> <artifactId>spring-context-support</artifactId> <version>${ springframework.version}</version> </dependency> <dependency> <groupid>o Rg.springframework</groupid> <artifactId>spring-test</artifactId> <version>${s pringframework.version}</version> <scope>test</scope> </dependency> &LT;/DEP Endencies> </project>