JCenter 最终关闭对 Gradle 插件门户的影响

2024 年 7 月 5 日

Louis Jacomet

通用

引言

既然 JFrog 已确认 JCenter 将永久重定向到 Maven Central，我们认为让 Gradle 插件门户的用户了解该决定对门户及其构建的影响非常重要。这篇文章是继 JCenter 重定向到 Maven Central 一天后 我们的报告 之后发布的。

仍在直接使用 JCenter 的用户也应参阅 我们的原始博客文章，了解 JCenter 的更改及其对 Gradle 构建的总体影响。

即将到来的插件门户变更 #

JCenter 将永久重定向到 Maven Central。因此，Gradle 插件门户将不再充当 JCenter 代理，而是充当 Maven Central 代理。

Gradle 插件门户将继续返回重定向 (303 See Other) 以处理无法提供的构件查询。从 2024 年 7 月 15 日起，这些重定向将指向 Maven Central 而非 JCenter。

此更改可能会影响现有 Gradle 构建

• 使用其依赖项仅在 JCenter 上可用的插件的构建将无法解析。
• 配置为使用 Gradle 插件门户作为常规构件仓库（不建议）的构建可能会受到影响。有关更多信息，请参阅 我们的原始博客文章。

我们旨在记录对插件门户提供的 Gradle 插件的潜在影响。阅读我们下面的分析，了解如何最大限度地减少对构建的影响。

影响分析 #

我们进行了两项主要分析

1. 对于 Gradle 插件门户已知的所有插件，确定如果它们的传递依赖项仅在 Maven Central 上解析，哪些插件将无法解析。请参阅下面的 插件解析影响。
2. 对于 Gradle 插件门户上所有现有的重定向流量，确定如果重定向到 Maven Central 而非 JCenter，会有多少失败。请参阅下面的 依赖解析影响。

插件解析影响 #

在分析时（2024 年 6 月 6 日），插件门户提供了 7,400 多个插件，每个插件至少有一个已发布的版本。仅考虑每个插件的 最新版本，我们发现以下情况：

1. 322 个唯一的插件 ID 无法解析，即使 JCenter 可用。这表明它们的使用需要额外的仓库配置。这些已被排除在其余调查之外。
2. 351 个唯一的插件 ID 无法解析，因为在使用 Maven Central 作为代理目标时缺少传递依赖项。
3. 这些故障指向 206 个唯一的 <group>:<artifact>，总共有 244 个唯一的依赖项（唯一的 <group>:<artifact>:<version>）在 JCenter 上可用，但在 Maven Central 上不可用。
4. 此外，104 个插件依赖于上述 351 个失败插件中的一个或多个。由于传递依赖项，它们很可能也无法解析。

有关我们如何获得这些数字的详细信息，请参阅下面附录中的 测试方法。

我们还根据每个插件版本的发布年份分析了这些数据。您可以在下表中看到细目分类：

从数据中可以看出，最近的插件受此变化影响较小，而较旧的插件更有可能受到影响。这意味着较旧的构建更有可能受到即将到来的变化的影响。

后续步骤 #

插件门户上受影响的 351 个插件的最新版本描述将更新，以表明它们依赖于 Maven Central 上不可用的依赖项。

我们还将通过电子邮件通知受影响的插件作者，告知他们此问题。我们希望那些仍在维护其插件的人能够解决此问题。

要检查您的构建是否受到影响，请参阅下面的 资源部分，其中提供了列出受影响插件和依赖项的文件。

依赖解析影响 #

除了下载插件之外，Gradle 插件门户还用作项目依赖项的常规构件仓库。虽然这从未被推荐，但它之所以有效，是因为插件门户过去实际上是 JCenter 的代理，未来将是 Maven Central 的代理。

在 7 天内，Gradle 插件门户为无法提供的构件提供了超过 10 亿次重定向 (303 See Other)。在分析此流量时，我们仅限于与 Maven 仓库模式匹配的文件请求。这些请求总计 500 万个不同的 GAV。其中，我们通过关注带有 .pom、.module 或 .jar 文件扩展名的请求，将总数减少到 480 万。

从数据中可以看出，构建请求公司内部构件，我们不期望在公共仓库中找到这些构件。Gradle 有一个 仓库内容过滤功能，可以加快构建速度并隐藏该信息。我们还看到构建或镜像配置错误。由于这些原因，我们不会公开此数据。

Sonatype，Maven Central 的管理方，确认在 480 万个请求中，只有 25% 与 Maven Central 已知的 GAV 匹配。

我们还查看了 JFrog 分享的关于 JCenter 的数据，发现只有额外 3% 的失败请求在 JCenter 上解析。提醒一下，JCenter 本身正在提供 Maven Central 的所有内容以及它托管的文件。

从插件门户方面来看，当请求无法在 Maven Central 上找到依赖项时，我们无法知道发出请求的构建是否失败。这是因为请求构建可以配置额外的仓库。

我们继续不鼓励将 Gradle 插件门户用作代理。如果您的构建逻辑需要非插件依赖项，请将 Maven Central 等仓库添加到您的构建配置中。并确保它具有您需要的依赖项！

资源 #

以下是我们分析过程中收集的资源列表。它们可能有助于评估即将到来的更改对您的构建的影响。

• 受影响的插件：Maven Central 中缺少依赖项的 351 个插件列表。
• 受影响的插件依赖项：Maven Central 中未找到的 244 个插件依赖项列表。
• 受传递影响的插件：依赖于 351 个失败插件之一的 104 个插件列表。

这些分析结果中出现的 org.gradle 坐标怎么办？ #

许多 Gradle 构件都受到此更改的影响：依赖项和插件。

org.gradle:gradle-* 依赖项 #

一些较旧版本（2 和 3）的 Gradle 构件已发布到 JCenter。它们也发布到 Gradle 管理的仓库，应从该位置使用。

但是，由于依赖这些构件而损坏的插件不应该一开始就有该依赖项。插件在构建中运行时，将使用正在使用的 Gradle 分发中的类。无法加载这些类的不同版本。因此，我们可以认为这些受影响插件的元数据不正确。我们建议受影响的用户通过 组件元数据规则 清理这些依赖项，或 将上面指示的仓库添加到其插件解析中。

org.gradle.guides.* 插件 #

一些较旧的 Gradle 插件受到影响，因为它们依赖于仅在 JCenter 上可用的软件包。这些插件已整合到三个 Gradle 文档插件 下，这些插件有不受影响的更新版本。用户应升级其插件依赖项。

附录 #

插件解析测试方法 #

本节描述了确定 插件解析影响 的测试方法。

1. 编写一个 Gradle 构建，使用 gradlePluginPortal() 作为仓库来解析插件作为常规依赖项。这意味着我们没有尝试 应用 插件。
   • 我们添加了另一个仓库，具有以下配置，以考虑依赖 Google 仓库的 Android 生态系统

      google() {
      	content {
       	includeGroupByRegex("com\\.android.*")
       	includeGroupByRegex("com\\.google.*")
       	includeGroupByRegex("androidx.*")
       	includeGroupByRegex("android.*")
      	}
      }
     

2. 收集这些解析尝试的失败。这些失败是 322 个失败的插件，即使 JCenter 可用。
3. 收集成功解析的直接依赖项。
4. 针对 Maven Central 解析这些直接依赖项，同时考虑依赖排除项。再次，使用上面所示的额外 google() 仓库配置。插件依赖项在此阶段被排除，因为它们预计仅针对插件门户解析。
5. 收集失败。如果使用 Maven Central 而不是 JCenter，这些失败是 351 个失败的插件。
6. 处理依赖数据。这给了我们 206 个唯一的 <group>:<artifact> 的 244 个依赖项。
7. 考虑对失败插件之一具有插件依赖项的插件。这又增加了 104 个插件。

讨论