每个依赖可以包含的元素有：
groupId、artifactId、version：依赖的基本坐标，最重要
type：依赖的类型，对应于项目坐标定义的packaging，多数情况该元素不比声明，默认值为jar
-
scope：依赖的范围，依赖的范围是用来控制三种classpath（编译classpath、测试classpath、运行classpath），maven在编译项目主代码、编译执行测试、运行maven项目时个需要三套不同的classpath。
maven主要有以下几种依赖范围：
compile：默认范围。对于编译、测试、运行三种classpath均有效。test：仅对测试classpath有效，比如JUnitprovided：编译和测试classpath有效，但在运行时无效，比如servlet-apt，编译测试时需要此依赖，但运行时容器已提供，因而不需要重复引入runtime：对于测试和运行classpath有效，比如JDBC驱动实现system：与provided范围一致，但使用system范围的依赖时必须通过systemPath元素显式地指定依赖文件的路径。由于此类依赖不是通过maven仓库解析的，而且往往与本机系统绑定，可能造成构建的不可移植，因而要慎用。systemPath可以引用环境变量。-
import：导入依赖范围。不会对三种classpath产生实际影响。以上所有的依赖范围均对测试有效
传递性依赖：当前依赖的构件a本身有其他的依赖构建b，导致maven项目需要将构件b也导入，maven会自动帮助导入，而如果不适用maven，需要自己不断地去添加构件，麻烦！
依赖范围会影响传递性依赖，好比A依赖于B，B依赖于C，称A对于B是第一直接依赖，B对于C是第二直接依赖，二者决定了传递性依赖的范围，见下表。
依赖传递对依赖范围的影响.png
依赖调解：对于传递依赖，可能存在的情况是如下A->B->x(1.0)和A->D->F->x(2.0)和A->K->x(3.0)，maven采用两条原则，路径最近者原则和第一声明者原则，如上，最终选择x(1.0)
-
optional：标记依赖是否可选，值为true和false。
存在一些情况如下：A依赖于B，B依赖于C和D，C和D对于B都是可选依赖（C和D可能是互斥的因而可选），即A->B，B->C（可选），B->D（可选），此时C和D不会对A造成传递依赖，因此，如果A依赖于B，B使用的C的函数，则A需要显示声明C这一依赖。
理想情况下，可选依赖不应该被使用，除非某项目为了实现多个特性。然而，在面向对象设计中，有单一职责原则。
-
exclusions：排除传递性依赖
存在一些情况如下：传递依赖A->B->C- C是一个SNAPSHOT版本，不稳定，此时需要排除掉这个C换为其他并且显式声明；
- C不在maven的中央仓库，需要使用另外一个替代C。需要注意的是，声明excusion的时候只需要groupId和artifactId，不需要version，因为依赖图中通过groupId和artifactId即可唯一定位此依赖，不可能存在groupId和artifactId相同但是version不同的两个依赖
多数依赖声明只包含基本坐标。
归类依赖：相当于提取出常量为public final
优化依赖：去除多余依赖，显示声明必要的依赖。
mvn dependency:list 查看当前所有已解析依赖
mvn dependency:tree 将以上展示为依赖树
mvn dependency:analyze 结果会分为两个部分——未显示声明的依赖、项目中未使用的但是显示声明的依赖。
对于前者，需要显示声明项目中直接用到的依赖。
对于后者，此命令只分析编译主代码和测试代码需要用到的依赖，对于一些执行测试和运行的依赖无法检测，需要慎重删除。