一、依赖的基本配置
根元素project下的dependencies可以包含多个 dependence元素,以声明多个依赖。每个依赖都应
该包含以下元素:
1. groupId, artifactId, version :
依赖的基本坐标, 对于任何⼀个依赖来说,基本坐标是最重要的,
Maven根据坐标才能找到需要的依赖。
2. Type :
依赖的类型,⼤部分情况下不需要声明。 默认值为jar
3. Scop e: 依赖范围(compile,test,provided,runtime,system)
- compile: 编译依赖范围。
如果没有指定,就会默认使⽤该依赖范围。使⽤此依赖范围的Maven依赖,对于编译、测
试、运⾏三种classpath都有效。
- test: 测试依赖范围。
使⽤此依赖范围的Maven依赖,只对于测试classpath有效,在编译主代码或者运⾏项⽬的使
⽤时将⽆法使⽤此类依赖。典型的例⼦就是JUnit,它只有在编译测试代码及运⾏测试的时候
才需要。
- provided: 已提供依赖范围。
使⽤此依赖范围的Maven依赖,对于编译和测试classpath有效,但在运⾏时⽆效。典型的例
⼦是servlet-api,编译和测试项⽬的时候需要该依赖,但在运⾏项⽬的时候,由于容器已经
提供,就不需要Maven重复地引⼊⼀遍(如:servlet-api)。
- runtime: 运⾏时依赖范围。
使⽤此依赖范围的Maven依赖,对于测试和运⾏classpath有效,但在编译主代码时⽆效。典
型的例⼦是JDBC驱动实现,项⽬主代码的编译只需要JDK提供的JDBC接⼝,只有在执⾏测试
或者运⾏项⽬的时候才需要实现上述接⼝的具体JDBC驱动。
- system: 系统依赖范围。
该依赖与三种classpath的关系,和provided依赖范围完全⼀致。但是,使⽤system范围依
赖时必须通过systemPath元素显式地指定依赖⽂件的路径。由于此类依赖不是通过Maven仓
库解析的,⽽且往往与本机系统绑定,可能造成构建的不可移植,因此应该谨慎使⽤。
4. Optional:
标记依赖是否可选
5. Exclusions:
⽤来排除传递性依赖。
二、 依赖范围
⾸先需要知道,Maven在编译项⽬主代码的时候需要使⽤⼀套classpath。
⽐如:编译项⽬代码的时 候需要⽤到spring-core,该⽂件以依赖的⽅式被引⼊到classpath中。 其次, Maven在执⾏测试的时候 会使⽤另外⼀套classpath。 如:junit。 最后在实际运⾏项⽬时,⼜会使⽤⼀套classpath, spring-core需要在该classpath中,⽽junit不需要。
那么依赖范围就是⽤来控制依赖与这三种classpath(编译classpath,测试classpath,运⾏时
classpath)的关系, Maven有以下⼏种依赖范围:
1. Compile 编译依赖范围:
如果没有指定,就会默认使⽤该依赖范围。 使⽤此依赖范围的Maven依
赖, 对于编译,测试,运⾏都有效。
2. Test:
测试依赖范围。 只在测试的时候需要。⽐如junit
3. Provided:
已提供依赖范围。 使⽤此依赖范围的Maven依赖,对于编译和测试有效, 但在运⾏
时⽆效。 典型的例⼦是servlet-API, 编译和测试项⽬的需要, 但在运⾏项⽬时, 由于容器已经提
供, 就不需要Maven重复地引⼊⼀遍。
4. Runtime:
运⾏时依赖范围。 使⽤此依赖范围的Maven依赖,对于测试和运⾏有效, 但在编译代
码时⽆效。 典型的例⼦是:jdbc驱动程序, 项⽬主代码的编译只需要jdk提供的jdbc接⼝,只有在
执⾏测试或者运⾏项⽬的时候才需要实现上述接⼝的具体jdbc驱动。
5. System:
系统依赖范围。 ⼀般不使⽤。
三、传递性依赖
让我们在使⽤某个jar的时候就不⽤去考虑它依赖了什么。也不⽤担⼼引⼊多余的依赖。
Maven会解析各个直接依赖的POM,将那些必要的间接依赖,以传递性依赖的形式引⼊到当前项
⽬中。
注意: 传递依赖有可能产⽣冲突!!
冲突场景:
如果A下同时存在两个不同version的C,冲突!!(选取同时适合A、B的版本)