maven日记（二）：坐标和依赖
>> maven坐标由5个元素组成：
* groupId：定义当前maven项目隶属的实际项目
maven项目和实际项目不一定是一对一关系，比如SpringFramework这一实际项目，其对应的maven项目会有很多，比如spring-core、spring-context等。这是由于maven中模块的概念，因此一个实际项目往往会被划分成很多模块。其次，groupId不应该对应项目隶属的组织或公司，因为一个组织下面会有很多项目。最后，groupId表示方式与Java包名表示方式类似，通常与域名反向一一对应。比如org.sonatype.nexus，org.sonatype是公司域名，而nexus表示Nexus这一实际项目，该groupId与nexus.sonatype.org域名对应。
* artifactId：定义实际项目中的一个maven项目（模块），推荐做法是使用实际项目名称作为artifact的前缀，比如nexus-indexer
* version：定义maven项目当前所处的版本
* packaging：定义maven项目打包方式，默认为jar
* classifier：定义构建输出的一些附属构件，附属构件与主构件对应，如nexus-indexer-2.0.0.jar，该项目可能还会通过使用一些插件生成如nexus-indexer-2.0.0-javadoc.jar、nexus-indexer-2.0.0-sources.jar等附属构件，这时候，javadoc和sources就是这两个附属构件的classifier。这样，附属构件也就拥有了自己的唯一坐标。注意classifier是不能直接定义的，它是由附加插件帮助生成的。
注：构件生成的文件名规则为：artifactId-version[-classifier].packing，此外，maven仓库的布局也是基于maven坐标。
>> 依赖的配置：
<dependencies> <dependency> <groupId>com.icegreen</groupId> <artifactId>greenmail</artifactId> <version>1.3.1b</version> <type>...</type> <scope>test</scope> <optional>...</optional> <exclusions> <exclusion> ... </exclusion> <exclusion> ... </exclusion> </exclusions> </dependency> <dependency> ... </dependency></dependencies>
每个依赖可以包含的元素有：
* groupId、artifactId和version：依赖的基本坐标
* type：依赖的类型，对应于项目坐标定义的packaging，大部分情况下都为默认的jar
* scope：依赖的范围
* optional：标记依赖是否可选
* exclusions：排除传递性依赖
>> 依赖范围scope
依赖范围就是用来控制依赖与这三种classpath（编译classpath、测试classpath、运行classpath）的关系，maven有以下几种依赖范围：
* compile：编译范围，如果没有指定，默认就是这个范围，使用此范围的maven依赖，对于编译、测试、运行三种classpath都有效。
* test：测试依赖范围，只对测试classpath有效，在编译主代码或者运行项目的时候无法使用此依赖，典型就是junit
* provided：已提供依赖范围。对于编译和测试有效，但在运行时无效。典型例子就是servlet-api，编译和测试项目时候需要用到该依赖，但在运行项目的时候，由于容易已经提供，就不需要重复的引入了。
* runtime：运行时依赖，对于测试和运行有效。但是编译无效，典型就是JDBC-Driver实现，项目主代码的编译只需要JDK提供的JDBC接口，只有在执行测试或者运行项目的时候才需要实现上述具体的JDBC驱动。
* system：系统范围依赖。该依赖于三种classpath的关系，和provided完全一致。但是，使用system范围的依赖时候必须通过systemPath元素显示指定依赖文件的路径。由于此类依赖不是通过maven仓库解析的，而是往往与本机系统绑定，可能造成构建的不可移植，因此谨慎使用，systemPath可以引用环境变量，如：
<dependency> <groupId>javax.sql</groupId> <artifactId>jdbc-stdext</artifactId> <version>2.0</version> <scope>system</scope> <systemPath>${java.home}/lib/rt.jar</systemPath></dependency>* import：导入依赖范围。该依赖不会对三种classpath产生实际影响
图示说明依赖范围与classpath关系：
12345????????????compile???? test??? provided??? runtimecompile???? compile???? --????? --????????? runtimetest??????? test??????? --????? --????????? testprovided??? provided??? --????? provided??? providedruntime???? runtime???? --????? --????????? runtime>> 依赖调解：
如果A -> B -> C -> X1.0，然后还有一个 A -> D -> X2.0，一个项目依赖X的两个版本，那么应该选哪个呢，maven依赖调解原则：
第一原则：路径最近者优先，比如上面，肯定是X2.0路劲优先
第二原则：如果路径长度一样，那么第一声明者优先，也就是在pom的dependence里面优先声明的优先使用。哦也~~
>> 可选依赖
如果A -> B，而B -> X并且 B-> Y，但是如果X和Y是optional的时候，A不依赖X和Y，也就是X和Y不会被传递。
<dependencies> <dependency> <groupId>...</groupId> <artifactId>...</artifactId> <version>1.0.0</version> <optional>true</optional> </dependency></dependencies>当其他项目需要依赖这个jar包的时候，需要自己去显示的声明。但是在理想情况下，是不应该出现这个传递依赖的。
>> 排除依赖
可以使用exclusion排除传递依赖，不解释
>> 归类依赖
在pom中定义版本变量version，统一使用版本变量名，方便升级，不解释
>> 优化依赖
项目中引入各种依赖的时候，可能会有很多依赖相同的jar包但是版本不一致的，但是maven非常智能的通过它的依赖调解最后确保只会引用唯一一个版本。
可以运行命令 ：
mvn dependency:list：去查看当前项目已解析的依赖列表
mvn dependency:tree：以树状结构查看依赖树
mvn dependency:analyze：分析项目的依赖问题