Maven（3）：坐标和依赖

Maven的坐标元素：

groupID：定义当前Maven项目隶属的实际项目 一个实际项目会被划分很多模块

artifactID：实际项目中的一个Maven模块

version：项目的版本

packaging：打包方式

classifier：用来帮助定义构件输出的一些附属构件

Maven内置了一个中央仓库的地址（http://repo1.maven.org/maven2）该中央仓库包含了世界上大部分流行的开源项目

构件 Maven会在需要的时候去那里下载

依赖：

groupID artifactID和version：依赖的基本坐标

type：依赖的类型 对应坐标中的packaging 默认为jar

scope：依赖的范围

optional：标记依赖是否可选

exclusions：用来排除传递性依赖

依赖的范围（scope）:

Maven在编译项目主代码的时候需要使用一套classpath 编译和执行测试的时候会使用另一套classpath 最后实际运行的时候又会使用另一套classpath

依赖范围就是用来控制依赖与这三种classpath（编译classpath 测试classpath  运行classpath）的关系

compile：编译依赖范围 默认 此依赖范围的Maven依赖 对于编译 测试 运行三种classpath都有效

test：测试依赖 只对于测试classpath有效 在编译主代码或运行项目的时候将无法使用此类依赖（junit）

provided：已提供依赖范围 对于编译和测试有效 运行无效（servlet-api 容器提供）

runtime：运行时依赖 测试和运行有效 编译无效（jdbc 项目主代码的编译只需要jdk提供的jdbc接口）

system：系统依赖范围 该依赖与三种classpath的关系 和provided依赖范围完全一致 但是 使用system范围的依赖时必须通过systemPath元素显式地指定依赖文件的路径 此类依赖不是通过Maven仓库解析的 而且往往与本机系统绑定 可能造成构建的不可移植 因此需要谨慎使用

    <systemPath>${java.home}/lib/rt.jar</systemPath>

import：导入依赖范围 不会对三种classpath产生实际的影响

传递性依赖：

当A 依赖B B依赖C 在A中导入B后会自动导入C C是A的传递依赖 如果C依赖D则D也可能是A的传递依赖

依赖无法传递时 jar无法使用（Eclipse中变灰） 重新导入依赖就行

依赖冲突解决：

1.先声明的依赖先使用

2.pom.xml中路径近者先使用

排除依赖

锁定版本