一.依赖的配置
<project> <dependencies> <groupid></groupid> <artifactId></artifactId> <version></version> <type></type> <scope></scope> <optional></optional> <exclusions> <exclusion> </exclusion> </exclusions> </dependencies> </project>groupId、artifactId、version:依赖的基本坐标,Maven根据坐标才能找到需要的依赖。
type:依赖的类型,对应于项目坐标定义的packaging。大部分情况下,该元素不必声明,其默认为jar
scope:依赖的范围。
optional:标记依赖是否可选。
exclusions:用来排除传递性依赖。
注:大部分依赖声明只包含基本坐标,然而在一些特殊情况下,其他元素至关重要。
二.依赖范围
依赖范围就是用来控制依赖与这三种classpath(编译:classpath、测试:classpath、运行:classpath)的关系。
Maven依赖范围:
compile:编译依赖范围。如果没有指定,就会默认使用该依赖范围,使用此依赖范围的Maven依赖,
对于编译、测试、运行三种classpath都有效。典型的例子是:spring-core,在编译、测试和运行的时候都需要使用此依赖。
test:测试依赖范围。使用此依赖范围的Maven环境,只对于测试classpath有效,在编译主代码或者运行项目的时候将无法使用此类依赖。
典型的例子是JUnit,它只有在编译测试代码及运行测试的时候才使用。
provided:以提供依赖范围。使用依赖范围的Mavne依赖,对于编译和测试class-path有效,但在运行时无效。典型的例子是servlet-api,编译和测试项目的时候
需要该依赖,但在运行项目的时候,由于容器已经提供,就不需要Maven重复地引入。
runtime:运行时依赖范围。使用此依赖范围的Maven依赖,对于测试和运行class-path有效,但在编译主代码时无效。典型的例子是JDBC驱动实现,项目主代码的编译
只需要JDK提供的JDBC接口,只有在执行测试或者运行项目的时候才需要实现上述接口的具体JDBC驱动。
system:系统依赖范围。该依赖与三种classpath的关系,和provided依赖范围完全一致。但是,使用system范围的依赖时必须通过systemPath元素显示地指定依赖文件
的路径。由于此类依赖不是通过Mavne仓库解析的,而且往往与本机系统绑定,可能造成构建的不可移植,因此应该谨慎使用。
import:导入依赖范围。该依赖范围不会对三种classpath产生实际的影响。三:传递性依赖
什么是传递性依赖?
传递性依赖就是一个项目需要依赖其它项目来完成功能,例如在开发中我们会使用spring项目,我们就会手动添加spring的jar包,这就是一种依赖,而spring又可能去依赖其它项目jar包,这就形成了一种传递性。(纯属个人见解),缺点:手动往往会添加一些不必要的jar包。
用Maven来管理项目时,Maven会解析各个直接依赖的POM,将那些必要的间接依赖,以传递性依赖的形式引入到当前项目中。
四:传递性依赖和依赖范围的关系
依赖范围不仅可以控制依赖与三种classpath的关系,还对传递性依赖产生影响。
假设:A依赖与B,B依赖与C,我们说A对于B是第一直接依赖,B对于C是第二直接依赖,A对于C是传递性依赖。,第一直接依赖的范围和第二直接依赖的范围决定了
传递性依赖的范围。