《Maven实战》阅读笔记整理（三）

今天阅读了第四章，主要是介绍了背景案例，作者对一个简单的注册功能，进行了全面的分析，和优秀的设计。

最后提到了一个Facade的模式，这是需要了解的地方。

前段时间妹子手术，去医院陪她了。在医院的时候，晚上看着她睡着了，我便看会儿书。但没有电脑，也就没有做笔记。

今日把笔记都补上，顺便再重温一遍。

第5章      坐标和依赖

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

groupId：定义当前Maven项目隶属的实际项目

artifactId：定义实际项目中的一个Maven项目（模块），推荐的做法是使用实际项目名称作为artifactId的前缀。

version：定义Maven项目当前所处的版本，遵循Maven版本规范

packaging：定义Maven项目的打包方式。打包方式与所生成构件的文件拓展名对应，但并不绝对。默认值为jar

classifier：用来帮助定义构件输出的一些附属构件。附属构件与主构件对应。注意不能直接定义项目的classifier，因为附属构件不是项目直接默认生成的，而是由附加的插件帮助生成的。

本书在测试邮件服务中提到了GreenMail邮件测试服务套件，这个需要进一步去了解。

GreenMail详细信息可访问 http://www.icegreen.com/greenmail/

相关参看博客 http://blog.csdn.net/jackiehff/article/details/8741988

Maven的依赖配置

根元素下的dependencies可以包含一个或多个dependency元素，以声明一个或多个项目依赖。

每个依赖可以包含的元素如下：

groupId、artifactId、version：依赖的基本坐标

type： 依赖的类型，对应于项目坐标对应的packaging

scope：依赖的范围

optional：标记依赖是否可选

exclusions：用来排除传递性依赖

scope依赖范围，用来控制依赖与三种classpath（编译classpath、测试classpath、运行classpath）的关系。

Maven有以下几种依赖范围：

compile（编译范围）

   compile 是默认的范围；如果没有提供一个范围，那该依赖的范围就是编译范
围。编译范围依赖在所有的classpath 中可用，同时它们也会被打包。

provided（已提供范围）
       provided 依赖只有在当JDK 或者一个容器已提供该依赖之后才使用。例如，
如果你开发了一个web 应用，你可能在编译classpath 中需要可用的Servlet
API 来编译一个servlet，但是你不会想要在打包好的WAR中包含这个Servlet
API；这个Servlet API JAR 由你的应用服务器或者servlet 容器提供。已提供
范围的依赖在编译classpath（不是运行时）可用。它们不是传递性的，也不会
被打包。

runtime（运行时范围）
       runtime 依赖在运行和测试系统的时候需要，但在编译的时候不需要。比如，
你可能在编译的时候只需要JDBC API JAR，而只有在运行的时候才需要JDBC
驱动实现。

test（测试范围）
       test 范围依赖在一般的编译和运行时都不需要，它们只有在测试编译和测试
运行阶段可用。

system（系统范围）
       system 范围依赖与provided 类似，但是你必须显式的提供一个对于本地系统
中JAR 文件的路径。这么做是为了允许基于本地对象编译，而这些对象是系统
类库的一部分。这样的构件应该是一直可用的，Maven 也不会在仓库中去寻找
它。如果你将一个依赖范围设置成系统范围，你必须同时提供一个systemPath
元素。注意该范围是不推荐使用的（你应该一直尽量去从公共或定制的Maven
仓库中引用依赖）。

import（导入依赖范围）

传递性依赖

1.何为传递性依赖

假如有一个account-email项目，该项目有一个org.springframework:spring-core:2.5.6的依赖，而实际上spring-core也有它自己的依赖，我们可以直接访问位于中央仓库的该构件的POM: http://repo1.maven.org/maven2/org/springframework/spring-core/2.5.6/spring-core-2.5.6.pom。该文件包含了一个commons-logging依赖。该依赖没有声明依赖范围，那么其依赖范围就是默认的compile。同时回顾一下account-email，spring-core的依赖范围也是compile。account-mail有一个compile范围的spring-core依赖，spring-core有一个compile范围的commons-logging依赖，那么commons-logging就会成为account-email的compile范围依赖，commons-loggins是account-email的一个传递性依赖。

有了传递性依赖机制，在使用spring的时候就不用去考虑它依赖了什么，也不用担心引入多余的依赖。maven会解析各个直接依赖的POM，将那些必要的间接依赖，以传递依赖的形式引入到当前的项目中。

2.传递性依赖和依赖范围 

依赖范围不仅可以控制依赖与三种classpath的关系，还对传递性依赖产生影响。上面的例子中，account-email对于spring-core的依赖范围是compile，spring-core对于commons-logging的依赖范围是compile，那么account-email对于commons-logging这一传递性依赖的范围也就是compile。假设A依赖B，B依赖C，我们说A对于B是第一直接依赖，B对于C是第二直接依赖，A对于C是传递性依赖。第一直接依赖的范围和第二直接依赖的范围决定了传递性依赖的范围，如下图，最左边一列表示第一直接依赖范围，最上面一行表示第二直接依赖范围，中间交叉单元格表示传递性依赖范围。

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

规律：1，当第二依赖的范围是compile的时候，传递依赖的范围与第一直接依赖的范围一致；

           2，当第二依赖的范围是test的时候，依赖不会得意传递；

           3，当第二依赖的范围是provided的时候，只有传递依赖的范围也是provided时传递，传递性依赖的范围同样为provided;

           4，当第二依赖的范围是runtime的时候，传递依赖的范围与第一直接依赖的范围一致，但compile除外，此时传递依赖的范围为runtime;

依赖调节：

第一原则：路径最近者优先；

第二原则：第一声明者优先；

注意：可选依赖不被传递，理想情况下，是不应该使用可选依赖的。

优化依赖：

1，可使用exclusions：用来排除传递性依赖（一些不必要的）

2，版本号的统一管理，归并依赖

3，使用命令查看当前项目的已解析依赖：mvn dependency:list

      查看当前项目的依赖树：mvn dependency:tree

      分析当前项目的依赖关系：mvn dependency:analyze

Used undeclared dependencies，意指项目中使用到的，但未显示声明的依赖。

Unused declared dependencies，意指项目中编译主代码和测试代码时未使用的，但显示声明的依赖，对于这种不能轻易删除。因为这些依赖可能在执行测试或运行时用到。

依赖版本界限：

(?, ?)  不包含量词。意思为：?<xx<? [?, ?]  包含量词。意思为：？<=xx<=? 例如：指定一个依赖界限：JUnit 3.8 - JUnit 4.0

<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>[3.8,4.0)</version>
<scope>test</scope>
</dependency>