依赖管理概述
- 自动化的依赖管理，目的是通过使用声明项目所需顶层依赖的方式，来解决本项目对外部类库的依赖问题，顶层依赖所需要的传递性依赖可以交由依赖管理器自动处理，也可以编写脚本实现特殊的要求。
- 类库的常见存在，java类库通常以JAR文件的形式存在，JAR文件规范不要求指定版本，但是一般的做法都会将版本号附加到JAR文件名上来表示一个特定的发布版本(比如，spring-web-3.1.3.RELEASE.jar)，在使用开发maven项目时，在pom文件中可以指定项目的标识信息(groupID、artificialID、version)，这样便于对类库进行仓库化管理，这种方式已经成为行业的一种约定。
自动化依赖管理的需求
至少也要明确下面两点：
- 明确类库的版本
这个不难理解，类库版本不同就是不同的jar包不同的代码了。 - 管理传递性依赖
对传递性依赖的管理，是解决依赖冲突的必要手段，但是手动确定一个项目类库所有依赖性传递是很困难的，一旦依赖冲突，就可能会造成编译和运行时类加载错误的问题。
所以自动化依赖管理需要寻求一个更完善的解决方案来管理依赖。实现依赖管理，最好能够将项目的依赖关系和各自的版本声明为项目的一种元数据(metadata)，利用这些元数据作为自动化过程的一部分，比如将这些依赖从中央仓库下载下来引入本地项目。
自动化依赖管理的概念和机制
在maven与Ivy中，依赖的配置通过xml文件来表示。配置由两部分组成：依赖标识符+各自版本 和 二进制仓库的地址。依赖管理器解析这些配置信息并自动从目标仓库中把依赖下载到本地机器上，类库可以定义传递性依赖作为元数据的一部分，依赖管理器在获取依赖过程中能够分析这些信息并解析依赖，如果发现依赖版本冲突，依赖管理器将尝试解决冲突。一旦下载了类库，类库就会存储在本地缓存中。在构建时会首先检查本地缓存中的类库，避免对仓库的不必要请求。
自动化依赖管理的挑战
依赖管理简化了对外部类库的处理，但是有时处理不足可能会损害构建的可靠性。
如下列一些情况发生：
- 潜在不可用的中央托管仓库
此种情况常发生于依赖于开源类库的企业级软件中。许多开源软件项目发布版本到中央托管仓库中(例如Maven Central)。如果对这些开源类库的构建只依赖于Maven Central，系统就可能会出现单点故障。万一仓库连接失败，本地缓存中也没有所需要的依赖，就可能出现错误。
为了避免这种情况，可以配置构建自定义的内部仓库。 - 坏元数据和依赖缺失
元数据被用来声明传递性依赖，依赖管理器根据元数据来建立依赖图，解决嵌套依赖关系。但是，元数据和仓库都不能保证元数据中声明的工件实际存在，或被正确定义甚至是所需要的。很可能会遇到依赖缺失的问题。
gradle的解决办法是，允许在依赖图的任何阶段去除传递性依赖，或者忽略它所提供的元数据，并设置自己的传递性依赖定义。
为了支持自定义策略来解决依赖冲突，gradle还提供了依赖报告