第五章 坐标和依赖

1.   Maven 定义了这样一组规则：世界上任何一个构件都可以使用 Maven 坐标唯一标识， Maven 坐标的元素包括 groupId 、 artifactId 、 version 、 packaging 、 classifier 。

 

2.   Maven 内置了一个中央仓库的地址（ http://repo1.maven.org/maven2 ），该中央仓库包含了世界上大部分流行的开源项目构件， Maven 会在需要的时候去那里下载。

 

3.   groupId 定义了当前 Maven 项目隶属的实际项目。一个实际项目往往会被划分成很多模块，一个模块可能就是一个 Maven 项目。 goupId 不应该对应项目隶属的组织或公司，因为一个组织或公司可能会有多个实际项目。 groupId 的表示方式与 Java 包名类似。

 

4.   artifactId 定义实际项目中的一个 Maven 项目（模块）。推荐使用实际项目名作为 artifactId 的前缀，如： nexus-indexer 。因为默认情况下 Maven 生成的构件会以 artifactId 开头，用实际项目名作为前缀就能方便从一个 lib 文件夹中找到某个实际项目的一组构件。

 

5.   version 定义了当时 Maven 项目所处的版本。

 

6.   packaging 定义了 Maven 项目的打包方式，通常与所生成构件的文件扩展名对应。不同的打包方式会影响构建的生命周期。比如 jar 打包与 war 打包会使用不同的命令。不定义 packaging 的时候，默认为 jar 。（ package 为 "maven-plugin" 的构件扩展名是 jar ）

 

7.  classifier 定义构建输出的一些附属构件。附属构件与主构件对应。如 Java 项目的 javadoc 和 sources 。 TestNG 项目默认是基于 Java 1.4 平台的，而它又提供了一个 jdk5 的附属构件。我们不能直接定义项目的 classifier ，因为附属构件不是项目直接默认生成的，而是由附加的插件帮助生成的。

 

8.  g roupId ， artifactId ， version 是必须定义的， packaging 是可选的， classifier 是不能直接定义的。

 

 

9.   项目构件的文件名与坐标相对应，一般为： artifactId-version[-classifier].packaging

 

10.   mvn clean install 会根据 POM 配置自动下载所需要的构件，执行编译、测试、打包等工作，最后将项目生成的构件安装到本地仓库中。

 

11.   根元素 project 下的 dependencies 可以包含一个或者多个项目依赖。一个依赖声明可以包含如下的一些元素：

 

<dependency>

  <groupId>…</groupId>

  <artifactId>…</artifactId>

  <version>…</version>

  <type>…</type>

  <scope>…</scope>

  <optional>…</optional>

  <exclusions>

    <exclusion>…</exclusion>

    …

  </exclusions>

</dependency> 

 

groupId 、 artifactId 和 version 是依赖的基本坐标。 type 为依赖的类型，对应于项目坐标定义的 packaging 。 scope 是依赖的范围。 optional 标记依赖是否是可选的。 exclusions 用来排除传递性依赖。

 

12.   依赖范围包含：

Compile ：编译依赖范围。对于编译、测试、运行三种 classpath 都有效。是默认的依赖范围。

Test ：测试依赖范围。只对测试 classpath 有效。如 Junit

Provided ：已提供依赖范围。只对编译、测试 classpath 有效。如 servlet-api ，运行时容器已提供。

Runtime ：运行依赖范围。只对测试和运行 classpath 有效。如 JDBC 驱动实现，编译主代码时只需要 JDK 提供的 JDBC 接口。

System ：系统依赖范围。与 Provided 依赖范围一致。但依赖是通过 systemPath 元素显式指定文件的路径，与本机系统绑定，一般无法移植。

Import ：导入依赖范围。不会对 3 种 classpath 产生实际影响。

scope	compile classpath	test classpath	runtime classpath	example
compile	Y	Y	Y	spring-core
test	-	Y	-	Junit
provided	Y	Y	-	servlet-api
runtime	-	Y	Y	JDBC 驱动实现
system	Y	Y	-	本地的Maven 类库文件

 

13.   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 + provided --> no dependency ? 而 provided + provided --> provided ? 个人认为此表完全不对。。。

 

14.   依赖调解第一原则：路径最近：

A->B->C->X(1.0) A->D->X(2.0)  X->2.0

依赖调解第二原则：最先声明：

A->B->X(1.0) A->D->X(2.0) 且 B 比 D 先声明， X->1.0

 

15.   如果项目 B 实现了两个特性，特性一依赖于项目 X ，特性二依赖于项目 Y ，而 X 与 Y 是互斥的。（比如 B 是一个持久层隔离包，支持多种数据库， X 为 MySQL 驱动， Y 为 PostgreSQL 驱动。）那么 X 与 Y 是 B 的可选依赖。如果 A 依赖 B ，则 A 不再传递依赖 X 与 Y 而需要显式地声明 X 或 Y 为其直接依赖。

 

16.   有时候希望排除某些传递依赖（比如传递依赖因版权限制不可用或者传递依赖是个 SNAPSHOT 版本）而显示地声明他们的替代者。可以在 <exclusion> 中声明想排除的传递依赖，而多增加一个 <dependency> 声明它的替代者。 <exclusion> 只用声明 groupId 和 artifactId 就行。

 

17.   对于来自同一个实际项目的多个项目依赖，他们版本应该是一致的，这样，可以先用 <properties> 定义一个版本号变量。如

<properties><spring.version>2.5.6</spring.version></properties> 。

然后在版本信息的位置使用 ${spring.version} 来引用它。

 

18.   可以执行 mvn dependency:list 或 mvn dependency:tree 查看已解析的依赖（ resolved dependency ）。

 

19.   可以执行 mvn dependency:analyze 来分析项目中的直接用到但未显示声明的依赖（ Used undeclared dependencies ）和声明了但未用到的依赖（ Unused declared dependencies ）。 Used undeclared dependencies 是项目直接用到了，但通过传递依赖引入的项目，这样当项目的直接依赖更新时，传递依赖也会随之更新，从而会导致项目代码与传递依赖不兼容。 Unused declared dependencies 并不是完全没用的依赖，只是在编译主代码和测试代码时没用，但可能会在执行测试和运行时用到。

评论

4 楼 851228082 2015-10-27  

851228082 写道

a----compile----b-----provided---c,结果是无依赖

按照我的理解，编译、测试时，a仍然会依赖c，只是运行时不再依赖，而由容器提供。所以，结果应该是provided


a----provided----b-----compile---c,结果就是provided
这个有点类似，编译、测试时，a依赖b，根据传递性也依赖c。但是打包时a不再依赖b，也就不再依赖c，改由容器提供b和c，所以，结果应该还是provided

以上两种是个人见解。

虽然结果时一样的，但是过程的分析，不一样。

3 楼 851228082 2015-10-27  

a----compile----b-----provided---c,结果是无依赖

按照我的理解，编译、测试时，a仍然会依赖c，只是运行时不再依赖，而由容器提供。所以，结果应该是provided


a----provided----b-----compile---c,结果就是provided
这个有点类似，编译、测试时，a依赖b，根据传递性也依赖c。但是打包时a不再依赖b，也就不再依赖c，改由容器提供b和c，所以，结果应该还是provided

以上两种是个人见解。

2 楼 Ranber 2015-04-29  

请问，为什么我的是默认的compile+compile，但是A->B,B->C,但是在A中始终不去远程库下载C，A也依赖不到C

1 楼 huiyibuzai 2012-07-01  

疑问：为什么 compile + provided --> no dependency ? 而 provided + provided --> provided ? 个人认为此表完全不对。。。


我看书的时候也觉得这表的关系有点不对劲。反正没懂他的表为啥会这样。