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中路径近者先使用
排除依赖
锁定版本