Maven coordinate dependency of Maven study notes

Maven coordinate dependency of Maven study notes

 

What are maven coordinates?

 

Maven coordinates: Any component in the world can be uniquely identified by maven coordinates. The maven coordinate elements include: groupId, artifactId, version, packaging, classifier

 

Detailed explanation of maven coordinates

 

1) groupId: defines the actual project to which the current maven project belongs, usually in reverse one-to-one correspondence with the domain name;

2) artifactId: defines a maven project (module) in the actual project, it is recommended to use the actual project as a prefix

3) version: defines the current version of the maven project (see the maven version specification);

4) packaging: The packaging method of maven projects, such as jar and war, is usually the same as the generated file extension, and will affect the life cycle of maven project construction;

5) classifier: Helps define some auxiliary components of the output, such as: spring-core-4.1.5.relase-sources.jar, here, sources represents a source package, and javadoc is common. A few plugins are needed to generate ancillary artifacts.

 

maven-dependent configuration

 

The dependencies under the root element project of pom.xml can contain multiple dependency elements. The dependencies of the project are declared through dependencies. Each dependency (dependency) contains the following elements:

1) groupId, artifactId, version: basic coordinates of dependencies;

2) type: the type of dependency, corresponding to the packaging defined by the project, the default value is jar;

3) scope: the scope of dependencies;

4) optional: Whether the flag dependency is optional (generally not recommended), for example, a project provides both the implementation of oracle and the implementation of mysql, and the user can only choose one of oracle or mysql when using it. , the dependencies on ojdbc and mysql-connector-bin are optional dependencies;

5) exclusions: exclude transitive dependencies.

 

Dependency scope (scope)

 

1) compile: compile dependency scope, scope default value; this dependency will be used when compiling, testing, and running

2) test: The dependency scope of the test, which is required for maven testing;

3) provided: The dependency scope has been provided, the compilation and testing are valid, and this dependency is not introduced at runtime. A typical example is servlet-api, which is provided by containers such as tomcat when running the project;

4) runtime: runtime dependency scope, required for running and testing, not required for compilation, typical example: jdbc driver implementation

5) system: The dependency scope of the system is the same as the dependency scope of the provider. The difference is that the path of the local package must be specified through systemPath. This dependency will not be resolved through the maven repository, such as:

 

<dependency>

   <groupId>com.alleyz.demo</groupId>

   <artifactId>demo-http</artifactId>

   <version>1.0</version>

   <scope>system</scope>

   <systemPath>${project.basedir}/src/lib/jave-1.2.jar</systemPath>

   <systemPath>${project.basedir}/src/lib/jave-1.2.jar</systemPath>

</dependency>

 

 

6) import: import dependency scope.

 

transitive dependency

Take a project demo that uses Spring as an example:

The Demo project depends on spring-core, and the spring-core project depends on commons-logging. At this time, a transitive dependency is formed. Demo is the first direct dependency for spring-core, and spring-core is for commons-logging. The second direct dependency, demo is a transitive dependency for commons-logging, the first direct dependency scope and the second direct dependency scope determine the scope of the transitive dependency, as shown in the figure:

 

  

dependent regulation

 

The first principle: the one with the closest path takes precedence;

The second principle: the first declaration takes precedence.

 

根据maven的传递性依赖机制，大部分情况下我们只需要关注项目的直接依赖。但是项目中出现依赖问题时，我们得知道maven传递性依赖选择的到底是哪个，下面例子：

 

项目A存在依赖关系：

1) A依赖B，B依赖C，C依赖X的1.0版本;

2) A依赖D，D依赖X的2.0版本，D依赖M的1.0版本；

3) A依赖E，E依赖于M的2.0版本；

 

此时，X作为项目A的传递依赖，根据依赖调节的第一原则，引入X的2.0版本；M作为项目A的传递依赖，引入的版本根据D和E的声明先后顺序决定（pom.xml文件中的先后顺序）。

 

归类依赖

 

对于同产品的不同依赖进行归类，保证其版本的一致性，一般使用maven属性进行归类依赖，如：

 

<properties>
<spring>4.2.5.RELEASE</spring>
</properties>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>${spring}</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>${spring}</version>
</dependency>
</dependencies>

 

 

优化依赖

优化规律：

显示声明项目中直接用到的依赖

分析办法：

运行 mvn dependency:analyze

查看Used undeclared dependencies下如果有依赖（直接依赖），则应该将此依赖在pom中声明，

查看Used declared dependencies下如果有依赖（显式声明但未在主代码中用到），则应该在确定无其他直接依赖使用此依赖时删除。

 

参考资料：《maven实战》