一：依赖配置
我们在实际开发汇中最常见的maven依赖如下，读者可以看到最基本的groupId,artifactId,version等元素组成。
1 <dependency> 2 <groupId>...</groupId> 3 <artifactId>...</artifactId> 4 <version>..</version> 5 <type>...</type> 6 <scope>...<scope> 7 <optional>...<optional> 8 <exclusions> 9 <exclusion> 10 </exclusion> 11 </exclusions> 12 <dependency>
1.groupId、artifactId和version:依赖的基本坐标，对于任何一个依赖来说，基本坐标最重要，Maven根据坐标才能找到需要的依赖。
2.type依赖类型，对于项目坐标定义的packaging。大部分情况下，该元素不必要声明，其默认值为jar。
3.scope 依赖范围。我们会在后面详细介绍。
4.optional:标记依赖是否可选。
5.exclusions:用来排除传递性依赖。
在实际应用中只包含最基本的坐标，然而在一些特殊情况下，其他元素至关重要。
二.依赖范围
依赖范围就是用来控制依赖与这三种classpath(编译classpath、测试classpath、运行classpath)的关系，Maven有以下几种依赖范围。
1.compile: 编译依赖范围。如果没有指定，就会默认使用该依赖范围。使用此依赖范围的maven依赖，对于编译 测试 运行三种的classpath都有效。
2.test：测试依赖范围。使用此依赖范围的Maven依赖，只对于测试的classpath有效，在编译主代码或者运行主代码的时候都无法依赖此类依赖。典型的例子是jUnit,它只有在编译测试代码及运行测试代码的时候才有效。
3.provided:以提供依赖范围。使用此依赖范围的maven依赖，对于编译和测试classpath有效，但在运行时无效。典型的例子是servlet-api，编译和测试项目的时候需要该依赖，但在运行的时候，由于容器已经提供，就不需要maven重复地引入一遍。打包的时候可以不用包进去，别的设施会提供。事实上该依赖理论上可以参与编译，测试，运行等周期。相当于compile，但是打包阶段做了exclude操作
4.runtime:运行时依赖范围。使用此依赖范围的maven依赖，对于测试和运行classpath有效，但在编译主代码时无效。典型的例子是JDBC驱动实现，项目主代码的编译只需要jdk提供的jdbc的接口，只有在执行测试或者运行测试的时候才需要实现上述接口的jdbc的驱动
5.system:系统依赖范围。从参与度来说，和provided相同，不过被依赖项不会从maven仓库下载，而是从本地文件系统拿。需要添加systemPath的属性来定义路径，该依赖与三种范围的classpath
和provided依赖范围完全一致。可能造成不可移植，谨慎使用。
6.import:导入依赖范围。该依赖范围不会对三种classpath产生实际的影响。只有在dependencyManagement下才有效果。
3.传递性依赖
A依赖B，B依赖C。当前项目为A，只当B在A项目中的scope，那么c在A中的scope是如何得知呢？
当C是test或者provided时，C直接被丢弃，A不依赖C；（排除传递依赖）
否则A依赖C，C的scope继承与B的scope。maven会解析各个依赖的pom，将那些必要的间接依赖，一传递性依赖的形式引入到当前的项目中。
原文地址：https://www.cnblogs.com/caibixiang123/p/9373674.html