为什么Gradle缓存多次包含依赖项？

Question

我们正在通过 Gitlab Pipeline Jobs 将 Gradle 缓存作为 ZIP 上传到 S3。解压其中一个 ZIP 文件（仅包含该.gradle文件夹）表明，许多依赖项多次包含完全相同的版本：1x injars-9和 1x in modules-2：

为什么会发生这种情况以及如何避免这种情况？因此，我们的 CI 缓存比实际需要的大 20-30%，特别是对于像 Kotlin 编译器这样的大依赖项：

JAR 之间的大小差异可归因于 JAR 文件压缩打开或关闭，它们在内容方面是相同的。

关于文件夹结构的官方解释没有.gradle帮助。

Answer 1

Gradle 的依赖项缓存专为提高效率和可靠性而设计。它包括两种主要存储类型：

1. 基于文件的下载工件存储，包括 jar 等二进制文件和 POM 和 Ivy 文件等原始下载元数据。下载的工件的存储路径包含 SHA1 校验和，这意味着可以轻松缓存两个具有相同名称但内容不同的工件 ( $GRADLE_USER_HOME/caches)。

2. 已解析模块元数据的二进制存储，包括解析动态版本、模块描述符和工件的结果。

jars-*您在 Gradle 缓存中看到的和目录modules-2属于这两种不同类型的存储。

该jars-*目录可能是指基于文件的下载工件存储。此目录中存储的每个工件都在其存储路径中包含 SHA1 校验和。这种设计允许 Gradle 缓存两个名称相同但内容不同的工件，并且还确保如果相同的工件已存在于具有相同 SHA1 校验和的缓存中，则不会多次下载该工件。

modules-2另一方面，该目录可能指的是已解析模块元数据的二进制存储。该目录以二进制格式保存依赖关系解析的各个方面的记录，包括将动态版本解析为具体版本的结果、特定模块的已解析模块元数据以及特定工件的已解析工件元数据。

这两个目录是不同的，因为它们具有不同的用途并存储不同类型的数据。

正如评论中与吸血鬼讨论的那样，我补充道：

当 Gradle 解析依赖项时，它会下载依赖项的 JAR 文件并将其存储在modules-2目录中。

如果对依赖项应用类路径转换，则转换结果（如果使用身份转换，则可能与原始结果相同）存储在目录中jars-*。这允许 Gradle 缓存转换的结果，避免将来在相同的转换中使用相同的依赖项时再次执行转换。

这可以解释相同的内容。

在减少 CI 缓存大小方面，考虑到 Gradle 缓存的工作方式，不同缓存目录中同一依赖项的多个实例可能是不可避免的。

但是，您也许能够将 CI/CD 管道配置为仅缓存必要的目录或文件，或者使用增量构建等技术来最大限度地减少需要缓存的数据量。
您还可以考虑定期手动或以编程方式清理 Gradle 缓存，以删除未使用或过时的文件。