Maven学习笔记之Maven坐标依赖
何为maven坐标？
Maven坐标：世界上任何一个构件都可以用maven坐标唯一标识，maven的坐标元素包括：groupId, artifactId, version, packaging, classifier
maven坐标详解
1) groupId：定义当前maven项目隶属的实际项目，通常与域名反向一一对应；
2) artifactId：定义实际项目中的一个maven项目（模块），推荐使用实际项目作为前缀
3) version：定义maven项目当前所处版本（参见maven版本规范）；
4) packaging：maven项目的打包方式，如jar、war，通常与生成的文件扩展名一致，并且会影响到maven项目构建的生命周期；
5) classifier：帮助定义输出的一些附属构件，如：spring-core-4.1.5.relase-sources.jar，此处，sources代表是一个源码包，常见的还有javadoc。生成附属构件时需要一些插件的帮助。
maven依赖的配置
在pom.xml的根元素project下的dependencies可以包含多个dependency元素，通过dependency声明项目的依赖，每个依赖（dependency）包含的元素有：
1) groupId, artifactId, version：依赖的基本坐标；
2) type：依赖的类型，对应项目定义的packaging，默认值为jar；
3) scope：依赖的范围；
4) optional：标记依赖是否可选（一般不建议使用），比如一个项目即提供了oracle的实现，又提供了mysql的实现，而用户在使用的时候只能选择oracle或者mysql中的一个，此时，对于ojdbc的依赖和mysql-connector-bin的依赖就属于可选依赖；
5) exclusions：排除传递性依赖。
依赖的范围（scope）
1) compile：编译依赖范围，scope默认值；编译、测试、运行的时候都会使用此依赖
2) test：测试的依赖范围，maven测试的时候需要此依赖；
3) provided：已提供依赖范围，编译、测试有效，运行时不在引入此依赖，典型的例子是servlet-api，运行项目的时候tomcat等容器已提供；
4) runtime：运行时依赖范围，运行和测试的时候需要，在编译的时候并不需要，典型的例子：jdbc的驱动实现
5) system：系统的依赖范围，与provider的依赖范围一致，区别是必须通过systemPath制定本地包的路径，此依赖不会通过maven仓库解析，如：
<dependency><span style="white-space:pre"></span><groupId>com.alleyz.demo</groupId><span style="white-space:pre"></span><artifactId>demo-http</artifactId><span style="white-space:pre"></span><version>1.0</version><span style="white-space:pre"></span><span style="color:#ff6666;"><scope>system</scope>
<span style="white-space:pre"></span><systemPath>${project.basedir}/src/lib/jave-1.2.jar</systemPath></span><span style="color:#ff6666;"><span style="white-space:pre"></span><systemPath>${project.basedir}/src/lib/jave-1.2.jar</systemPath></span></dependency>
6）import：导入依赖范围。
传递性依赖
以一个使用了Spring的项目demo举个例子：
Demo项目依赖于spring-core，而spring-core项目有依赖于commons-logging，此时，就形成了传递性依赖，demo对于对于spring-core是第一直接依赖，spring-core对于commons-logging是第二直接依赖，demo对于commons-logging是传递性依赖，第一直接依赖范围和第二直接依赖范围决定了传递性依赖的范围，如图：
|
第二直接依赖范围 |
||||
|
compile |
test |
provided |
runtime |
|
第一直接依赖范围 |
compile |
compile |
|
|
runtime |
test |
test |
|
|
test |
|
provided |
provider |
|
provided |
provided |
|
runtime |
runtime |
|
|
runtime |
|
依赖调节
第一原则：路径最近者优先；
第二原则：第一声明者优先。
根据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><span style="white-space:pre"></span><spring>4.2.5.RELEASE</spring></properties><dependencies><span style="white-space:pre"></span><dependency><span style="white-space:pre"></span><groupId>org.springframework</groupId><span style="white-space:pre"></span><artifactId>spring-core</artifactId><span style="white-space:pre"></span><version>${spring}</version><span style="white-space:pre"></span></dependency><span style="white-space:pre"></span><dependency><span style="white-space:pre"></span><groupId>org.springframework</groupId><span style="white-space:pre"></span><artifactId>spring-context</artifactId><span style="white-space:pre"></span><version>${spring}</version><span style="white-space:pre"></span></dependency></dependencies>
优化依赖
优化规律：
显示声明项目中直接用到的依赖
分析办法：
运行 mvn dependency:analyze
查看Used undeclared dependencies下如果有依赖（直接依赖），则应该将此依赖在pom中声明，
查看Used declared dependencies下如果有依赖（显式声明但未在主代码中用到），则应该在确定无其他直接依赖使用此依赖时删除。
参考资料：《maven实战》