Maven 坐标和依赖

Posted 2021-12-15 shi_zi_183

Maven坐标和依赖

坐标详解

Maven为各种构建引入了秩序，任何一个构件都必须明确定义自己的坐标，而一组Maven坐标是通过一些元素定义的，它们是groupId、artifactId、version、packaging、classifier。

	<groupId>org.sonatype.nexus</groupId>
    <artifactId>nexus-indexer</artifactId>
    <version>2.0.0</version>
    <packaging>jar</packaging>

这是nexus-indexer的坐标定义，nexus-indexer是一个对Maven仓编纂索引并提供搜索功能的类库，它是Nexus项目的一个子模块。

• groupId：定义当前Maven项目隶属的实际项目。首先，Maven项目和实际项目不一定是一对一的关系。比如SpringFramework这一实际项目，其对应的Maven项目会有很多，如spring-core、spring-context等。这是由于Maven中模块的概念，因此，一个实际项目往往会被划分成很多模块。其次，groupId不应该对应项目隶属的组织或公司。原因很简单，一个组织下会有很多实际项目，如果groupId只定义到组织级别，而后面我们会看到，artifactId只能定义Maven项目(模块)，那么实际项目这个层将难以定义。最后，groupId的表示方式与Java包名的表示方式类似，通常与域名反向一一对应。
• artifactId：该元素定义实际项目中的一个Maven项目，推荐的做法是使用实际项目名称作为artifactId的前缀。比如上例中的artifactId是nexus-indexer，使用了实际项目名称nexus作为前缀，这样做的好处是方便寻找实际构件。在默认情况下，Maven生成的构建，其文件名会以artifactId作为开头，如nexus-indexer-2.0.0.jar，使用实际项目名称作为前缀之后，就能方便从一个lib文件夹中找到某个项目的一组构件。考虑有5个项目，每个项目都有一个core模块，如果没有前缀，我们会看到很多core-1.2.jar这样的文件，加上实际项目名前缀之后，便能很容易区分foo-core-1.2.jar、bar-core-1.2.jar…
• version：该元素定义Maven项目当前所处的版本，如下例中nexus-indexer的版本是2.0.0。需要注意的是，Maven定义了一套完成的版本规范，以及快照的概念。
• packaging：该元素定义Maven项目的打包方式。首先，打包方式通常与所生成构建的文件推展名对应，如上例中packaging为jar，最终的文件名为nexus-indexer-2.0.0.jar，而使用war打包方式的Maven项目，最终生成的构建会有一个.war文件，不过这不是绝对的。其次，打包方式会影响到构建的声明周期，比如jar打包和war打包会使用不同的命令。最后，当不定义packaging的时候，Maven会使用默认值jar。
• classifier：该元素用来帮助定义构建输出的一些附属构建。附属构建与主构建对应，如上例中的主构件是nexus-indexer-2.0.0-sources.jar，该项目可能还会通过使用一些插件生成如nexus-indexer-2.0.0-javadoc.jar、nexus-indexer-2.0.0-sources.jar这样一些辅助构件，其包含了Java文件和源代码。这时候，javadoc和sources就是这两个附属构件的classifier。这样，附属构件也就拥有了自己唯一的坐标。还有一个关于classifier的典型例子是TestNG，TestNG的主构建是基于Java 1.4平台的，而它又提供了一个classifier为jdk5的附属构件。注意，不能直接定义项目的classifier，因为附属构件不是项目直接默认生成的，而是由附加的插件帮助生成。

上述5个元素中，groupId、artifactId、version是必须定义的，packaging是可选的(默认为jar)，而classifier是不能直接定义的。

依赖范围

首先需要知道，Maven在编译项目主代码的时候需要使用一套classpath。例如编写项目主代码的时候需要用到spring-core，该文件以依赖的方式被引入到classpath中，其次，Maven在编译和执行测试的时候会使用另一套classpath。例如JUnit就是一个很好的例子，他的依赖范围一般是test。最后，实际运行Maven项目的时候，又会使用一套classpath，上例中的spring-core需要在该classpath中，而JUnit则不需要。
依赖范围就是用来控制依赖与这三种classpath(编译classpath、测试classpath、运行classpath)的关系，Maven有以下几种依赖范围：

• compile：编译依赖范围。如果没有指定，就会默认使用该依赖范围。使用此依赖范围的Maven依赖，对于编译、测试、运行三种classpath都有效。典型的例子是spring-core，在编译、测试和运行的时候都需要使用该依赖。
• test：测试依赖范围。使用此依赖范围的Maven依赖，只对于的是classpath有效，在编译主代码或者运行项目的使用时将无法使用此类一阿里。典型的例子是JUnit，它只有在编译测试代码及运行测试的时候才需要。
• provided：已提供依赖范围。使用此依赖范围的Maven依赖，对于编译和测试classpath有效，但在运行时无效。典型的例子是servlet-api，编译和测试项目的时候需要该依赖，但在运行项目时，由于容器已经提供，就不需要Maven重复地引入一遍。
• runtime：运行时依赖范围。使用此依赖范围地Maven依赖，对于测试和运行classpath有效，但在编译主代码时无效。典型地例子是JDBC驱动实现，项目主代码只需要JDK提供地JDBC接口，只有在执行测试或者运行项目的时候才需要实现上述接口地具体JDBC驱动。
• system：系统依赖范围。该依赖与三种classpath的关系，和provided依赖范围完全一致。但是，使用system范围的依赖时必须通过systemPath元素显示地指定依赖文件地路径。由于此类依赖不是通过Maven仓库解析的，而且往往与本机系统绑定，可能造成构建的不可移植，因此应该谨慎使用。

<dependency>
	<groupId>javax.sql</groupId>
    <artifactId>jdbc-stdext</artifactId>
    <version>2.0.0</version>
    <scope>system</scope>
    <systemPath>$java.home/lib/rt.jar</systemPath>
</dependency>

• import(Maven 2.0.9及以上)：导入依赖范围。该依赖范围不会对三种classpath产生实际的影响。在Maven依赖和dependencyManagement的时候会介绍。

传递性依赖

何为传递性依赖

考虑一个基于Spring Framework的项目，如果不使用Maven，那么在项目中就需要手动下载相关依赖。由于Spring Framework又会依赖于其他开源类库，因此实际中往往会下载一个很大的如spring-framework-2.5.6-with-dependencies.zip的包，这里包含了所有Spring Framework的jar包，以及所有它依赖的其他jar包。这么做往往就引入了很多不必要的依赖。另一种做法是只下载spring-framework-2.5.6.zip这样一个包，这里不包含其他相关依赖，到实际使用的时候，再根据出错信息，或者查询相关文档，加入需要的其他依赖。很显然，这也是一件非常麻烦的事件。
Maven的传递性依赖机制可以很好地解决这一问题。以account-email项目为例，该项目有一个org.springframework:spring-core:2.5.6的依赖，而实际上spring-core也有它自己的依赖，我们可以直接访问位于中央仓库的该构件的POM:https://repo1.maven.org/maven2/org/springframework/spring-core/2.5.6/spring-core-2.5.6.pom

<dependency>
	<groupId>commons-logging</groupId>
	<artifactId>commons-logging</artifactId>
	<version>1.1.1</version>
</dependency>

该依赖没有声明依赖范围，那么其依赖范围就是默认的compile。同时回顾以下account-email，spring-core的依赖范围也是compile。
account-mail有一个compile范围的spring-core依赖，spring-core有一个compile范围的commons-logging依赖，那么commons-logging就会成为account-email的compile范围依赖，commons-logging是account-email的一个转递性依赖。
有了传递性依赖机制，在使用Spring Framework的时候就不用去考虑它依赖了什么，也不用担心引入多余的依赖。Maven会解析各个直接依赖的POM，将那些必要的间接依赖，以传递性依赖的形式引入到当前的项目中。

传递性依赖和依赖范围

假设A依赖于B，B依赖于C，我们说A对于B是第一直接依赖，B对C是第二直接依赖，A对C是传递性依赖。第一直接依赖和第二直接依赖决定了传定性依赖的范围，如表，最左边一列表示第一直接依赖范围，最上面一行表示第二直接依赖范围，中间的交叉单元格则表示传递性依赖范围。

	compile	test	provided	runtime
compile	compile	-	-	runtime
test	test	-	-	test
provided	provided	-	provided	provided
runtime	runtime	-	-	runtime

当第二直接依赖的范围是compile的时候，传递性依赖的范围与第一直接依赖的范围一致；当第二直接依赖的范围是test的时候，依赖不会得以传递；当第二直接依赖的范围是procided的时候，只传递第一直接依赖范围也为provided的依赖，且传递性依赖的范围同样为provided；当第二直接依赖的范围是runtime的时候，传递性依赖的范围同样为provided；当第二直接依赖的范围是runtime的时候，传递性依赖的范围与第一直接依赖的范围一致，但compile例外，此时传递性依赖的范围为runtime。

依赖调解

Maven引入的传递性依赖机制，一方面大大简化和方便了依赖声明，另一方面，大部分情况下我们只需要关心项目的直接依赖是什么，而不用考虑这些直接依赖会引入什么传递性依赖。但有时候，当传递性依赖造成问题的时候，我们就需要清楚地知道该传递性依赖是从哪条依赖路径引入的。
例如项目A有这样的依赖关系：A->B->C->X(1,0)、A->D->X(2,0)，X是A的传递性依赖，但是两条依赖路径上有两个版本的X，那么哪个X会被Maven解析使用呢？两个版本都解析显然是不对的，因为那会造成依赖重复，因此必须选择一个。Maven依赖调节的第一原则是：路径最近者优先。该例中X(1,0)的路径长度为3，而X(2,0)，Y(1,0)和Y(2,0)的依赖路径长度是一样的，都为2那么到底谁会被解析使用？在Maven2.0.8及之前的版本中，这是不确定的，但是从Maven2.0.9开始，为了尽可能避免构建的不确定性，Maven定义了依赖调节的第二原则；第一声明者优先。在依赖路径长度相等的前提下，在POM中依赖声明的顺序决定了谁会被解析使用，顺序最靠前的那个依赖优胜，该例中，如果B的依赖声明在C之前，那么Y(1,0)就会被解析使用。

可选依赖

假设有这样一个依赖关系，项目Ａ依赖于项目Ｂ，项目B依赖于项目X和Y，B对于X和Y的依赖都是可选依赖：A->B、B->X(可选)、B->Y(可选)。根据传递性依赖的定义，如果所有这三个依赖的范围都是comile，那么、Y就是A的compile范围传递性依赖。然而，由于这里X、Y是可选依赖，依赖将不会得以传递。话句话说，X、Y将不会对A有任何影响。
为什么要使用可选依赖这一特性？可能项目B实现了两个特性，其中的特性一依赖于X，特性二依赖于Y，而且这两个特性是互斥的，用户不可能同时使用两个特性。比如B是一个持久层隔离工具包，它支持多种数据库，包括mysql、PostgreSQL等，在构建这个工具包的时候，需要这两种数据库的驱动程序，但在使用这个工具包的时候，只会依赖一种数据库。

项目B的依赖声明代码

		<dependency>
			<groupId>mysql</groupId>
			<artifactId>mysql-connector-java</artifactId>
			<version>5.1.10</version>
			<optional>true</optional>
		</dependency>
		<dependency>
			<groupId>postgresql</groupId>
			<artifactId>postgresql</artifactId>
			<version>8.4-701.jdbc3</version>
			<optional>true</optional>
		</dependency>

上述XML代码片段中，使用<optional>元素表示mysql-connector-java和postgresql这两个依赖为可选依赖，它们只会对当前项目B产生影响，当其他项目依赖于B的时候，这两个依赖不会传递。因此，当项目A依赖于项目B的时候，如果其实际使用基于MySQL数据库，那么在项目A中就需要显式地声明mysql-connector-java这一依赖。
在理想的情况下，是不应该使用可选依赖的。在面对对象设计中，有个单一职责性原则，意指一个类应该只有一项职责，而不是糅合太多的功能。这个原则在规划Maven项目的时候也同样适用。在上面的例子中，更好的做法是为MySQL和PostgreSQL分别创建一个Maven项目，基于同样的groupId分配不同的artifactId，如com.juvenxu.mvnbook:project-b-mysql和com.juvenxu.mvnbook:project-b-postgresql，在各自的POM中声明对应的JDBC驱动依赖，而且不使用可选依赖，用户则根据需要选择使用不同项目。由于传递性依赖的作用，就不用再声明JDBC驱动依赖。

最佳实践

排除依赖

传递性依赖会给项目隐式的引入很多依赖，这极大地简化了项目依赖的管理，但是有些时候这种特性也会带来问题。例如，当前项目有一个第三方依赖，而这个第三方依赖由于某些原因依赖了另外一个类库的SNAPSHOT版本，那么这个SNAPSHOT就会成为当前项目的传递性依赖，而SNAPSHOT的不稳定性会直接影响到当前的项目。这时就需要排除掉该SNAPSHOT，并且在当前项目中声明该类库的某个正式发布的版本。还有一些情况，你可能也想要替换的某个传递性依赖，比如Sun JTA API，Hibernate依赖于这个JAR，但是由于版本的因素，该类库不在中央仓库中，而Apache Geronimo项目有一个对应的实现。这时你就可以排除Sun JAT API，在声明Geeronimo的JTA API实现。

		<dependency>
			<groupId>com.juvenxu.mvnbook</groupId>
			<artifactId>project-b</artifactId>
			<version>1.0.0</version>
			<exclusions>
				<exclusion>
					<groupId>com.juvenxu.mvnbook</groupId>
					<artifactId>project-c</artifactId>
				</exclusion>
			</exclusions>
		</dependency>
		<dependency>
			<groupId>com.juvenxu.mvnbook</groupId>
			<artifactId>project-c</artifactId>
		</dependency>

归类依赖

一个项目有很多关于Spring Framework的依赖，它们分别是org.springframework:spring-core:2.5.6、org.springframework:spring-beans:2.5.6、org.springframework:spring-context:2.5.6和org.springframework:spring-context-support:2.5.6，它们是来自同一项目的不同模块。因此，所有这些依赖的版本都是相同的，而且可以预见，如果将来需要升级Spring Framework，这些依赖的版本会一起升级。

<?xml version="1.0" encoding="UTF-8"?>
<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.example</groupId>
    <artifactId>accounte-mail</artifactId>
    <name>Account Email</name>
    <version>1.0-SNAPSHOT</version>

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

    <dependencies>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-core</artifactId>
            <version>$springframework.version</version>
        </dependency>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-beans</artifactId>
            <version>$springframework.version</version>
        </dependency>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-context</artifactId>
            <version>$springframework.version</version>
        </dependency>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-context-support</artifactId>
            <version>$springframework.version</version>
        </dependency>
    </dependencies>

</project>

这里简单用到了Maven属性，首先使用properties元素定义Maven属性，该例中定义了一个springframework.version子元素，其值为2.5.6。有了这个属性定义之后，Maven运行的时候会将POM中的所有的$springframework.version替换成实际值2.5.6。

优化依赖

Maven会自动解析所有项目的直接依赖和传递性依赖，并且根据规则正确判断每个依赖的范围，对于一些依赖冲突，也能进行调节，以确保任何一个构建只有唯一的版本在依赖中存在。在这些工作之后，最后得到的那些依赖被称为已解析依赖。可以运行如下的命令查看当前项目的已解析依赖。

mvn dependency:list

在此基础上，还能进一步了解已解析的信息，同时，每个依赖的范围也得以明确标示。
在此基础上，还能进一步了解以解析依赖的信息。将直接在当前项目POM声明的依赖定义为顶层依赖，而这些顶层依赖的依赖定义为第二层依赖，以此类推，有第三、第四层依赖。当这些依赖经Maven解析后，就会构成一个依赖树，通过这棵依赖树就能很清楚地看到某个依赖是通过那条传递路径引入的。

mvn dependency:tree

使用命令

mvn dependency:analyze

该结果中重要的是两个部分。首先是Used undeclared dependencies，意指项目中使用到的，但是没有显式声明的依赖，这里是spring-context。这种依赖意味着潜在的风险，当前项目直接在使用它们，例如有很多相关的Java import声明，而这种依赖是通过直接依赖传递进来的，当升级直接依赖的时候，相关传递性依赖的版本也可能发生变化，这种变化不易察觉，但是有可能导致当前项目出错。例如由于接口的改变，当前项目中的相关代码无法编译。这种隐藏的、潜在的威胁一旦出现，往往需要耗费大量的时间来查明真相。因此，显式声明任何项目中直接用到的依赖。
结果中还有一个重要的部分是Unused declared dependencies，意指项目中未使用的，但显式声明的依赖，这里有spring-core和spring-beans。需要注意的是，对于这样一类依赖，我们不应该简单地直接删除其声明，而是应该仔细分析。由于dependency:analyze只会分析编译主代码和测试代码需要用到地依赖，一些执行测试和运行时需要地依赖它就发现不了。当然，有时候确实能通过该信息找到一些没用的依赖，但一定要小心测试。