Gradle教程——（五）依赖管理

——《实战Gradle》中文版笔记

Gradle有它自己的依赖管理实现。Gradle摒弃了像Ivy和Maven这样的依赖管理工具的缺点，Gradle注重性能、构建可靠性以及可重复性。

1、依赖管理概述

几乎所有基于JVM的软件项目都需要依赖外部类库来重用现有的功能。Java类库通常以JAR文件的形式存在。JAR文件规范不要求你指定类库版本。然而，将版本号附加到JAR文件名上来标识一个特定的发布版本（比如，spring-web-3.1.3.RELEASE.jar）是常见的做法。随着项目由小变大，项目所依赖的模块和第三方类库会越来越多。组织和管理好JAR文件显得至关重要。

1.1 不完善的依赖管理技术

• 手动将JAR文件拷贝到开发机器上。这种处理依赖关系是最原始、非自动化而且最容易出错的方式。
• 使用JAR文件共享存储器（比如，一个共享网络驱动器的文件夹），它被安装在开发人员的机器上，或者通过FTP检索二进制文件。这种方式需要开发人员建立到二进制仓库的连接。新的依赖关系需要在有写权限和访问许可的情况下手动进行添加。
• 检查所下载的JAR文件，使其和版本控制系统中的项目源代码符合。这种方法不需要任何额外的设置，只需要将源代码和依赖绑定在一起。当更新仓库中的本地副本时，整个团队都可以检测到变化。缺点是一些不必要的二进制文件占用了仓库的大量空间。只要源代码发生变化，类库副本的变化就需要频繁地检入。如果你正在开发的多个项目彼此相互依赖，就更是如此。

1.2 自动化依赖管理的重要性

• 知道依赖的确切版本
• 管理传递性依赖

1.3 使用自动化依赖管理

在JAVA世界里，支持声明和自动化管理依赖的主要占主导地位的两个项目是：Apache Ivy，一个纯粹的依赖管理器，常常与Ant项目结合使用，以及Maven，包含有一个依赖管理器作为构建基础环境的一部分。

在Ivy和Maven中，依赖配置是通过XML描述符文件来表达的。配置由两部分组成：依赖标识符加各自的版本和二进制仓库的地址（比如，依赖仓库的HTTP地址）。依赖管理器解析这些信息并自动从目标仓库中把依赖下载到本地机器上。类库可以定义传递性依赖作为元数据的一部分。依赖管理器在获取依赖的过程中能够分析这些信息并解析依赖性。如果依赖的版本发生冲突，正如Hibernate核心类库例子所展示的那样，依赖管理器将尝试解决冲突。一旦下载，类库就会存储在本地缓存中。现在，所配置的类库在开发机器上是可用的，可以再构建中使用。后续构建会首先检查本地缓存中的类库，以避免对仓库的不必要请求。

使用依赖管理器让你摆脱了手动复制或组织JAR文件的困扰。Gradle提供了一个强大的适合上述架构的依赖管理实现。它通过Gradle的具有表述性的DSL来描述依赖配置，支持传递性依赖管理，并且与已有的仓库结合得很好。

1.4 自动化依赖管理的挑战

• 潜在不可用的中央仓库
  最广泛使用的仓库之一是Maven Central。如果构建只依赖于Maven Central，你的系统就可能会出现单点故障。万一仓库连接失败，而在本地缓存中又没有所需要的依赖，就有可能出现错误。

  为了避免出现这种情况，你可以配置构建使用自定义的内部仓库，让你完全控制服务器的可用性。

• 坏元数据和依赖缺失
  元数据和仓库都不能保障元数据中所声明的工作实际存在、被正确定义甚至是所需要。
  
  Gradle允许在依赖图的任何阶段去传递性依赖。或者，你也可以忽略它所提供的元数据，并且设置自己的传递性依赖定义。

  你会发现在不同版本的传递性依赖图中都有流行类库。这通常会出现在一些常用功能上，比如日志框架。依赖管理器试图找到一个智能的解决方案，根据某种解决策略选择一个合适的版本以避免版本冲突。当然有时候需要调整选择。Gradle提供了很有价值的依赖报告来解决需要知道哪些依赖引入了传递性依赖的哪个版本。

2、示例学习依赖管理

Jetty是一个在开发期间使用非常方便的容器。凭借Jetty的轻量级容器实现，它提供了快速的启动时间。

开源项目Cargo提供了支持Web因公部署到各种Servlet容器和应用服务器中的功能。在构建项目中，Cargo支持两种实现。一方面，可以使用Java API，细粒度地访问Cargo配置的每个方面。另一方面，可以选择执行一组预配置的Ant task，其封装了Java API。因为Gradle能够与Ant很好地集成，所以将基于Cargo Ant task来演示。

下图显示了在build.gradle文件中通过Gradle的DSL提供的依赖定义。依赖管理器在运行时执行这个配置，从中央仓库下载所需的工件，并将其存储到本地缓存。

3、依赖配置

3.1 理解配置API表示

配置可以直接在项目的根级别添加和访问，你可以使用插件所提供的的配置或声明自己的配置。每个项目都有一个ConfigurationContainer类的容器来管理相应的配置。配置在行为方面可以表现的很灵活。可以控制依赖解决方案中是否包含传递性依赖，定义解决策略（例如，如何解决工件版本冲突），甚至可以使配置扩展。

考虑配置的另一种方式是按照逻辑分组。通过配置分组依赖与Java类分包的概念相似。包针对其所包含的类提供了唯一的命名空间，这同样适用于配置。通过逻辑分组把职责相同的配置放到一起。

Java插件提供了6个现成的配置：complie、runtime、testCompile、testRuntime、archives和default。能不能只使用其中一个配置来声明依赖Cargo类库呢？通常可以，但会混淆相关的应用程序代码和为部署应用程序所编写的基础环境代码之间的依赖。在运行时将不必要的类库添加到发布包中可能导致不可预见的副作用，最好是避免发生这种情况。

3.2 自定义配置

为项目的配置容器添加一个配置后，可以直接通过名称来访问。

3.3 访问配置

从本质上讲，Ant task是Java类，遵循Ant的扩展端点来定义自定义逻辑。为了添加一个非标准的Ant task，如Cargo部署task，你需要使用Taskdef Ant task。为了解决Ant task实现类，Cargo的JAR文件中包含了需要分配的实现类。