最终 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 具有 仓库内容过滤功能，可以加快构建速度并隐藏该信息。我们还看到构建或镜像配置错误。由于这些原因，我们不会公开此数据。

Maven Central 的管理者 Sonatype 证实，在 480 万次请求中，只有 25% 的请求与 Maven Central 已知的 GAV 匹配。

我们还查看了 JFrog 共享的关于 JCenter 的数据，发现只有额外的 3% 的失败请求在 JCenter 上得到解决。提醒一下，JCenter 本身服务于 Maven Central 的所有内容及其托管的文件。

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

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

资源 #

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

• 受影响的插件：包含 351 个插件的列表，这些插件具有 Maven Central 中缺少的依赖项。
• 受影响的插件依赖项：包含 244 个插件依赖项的列表，这些依赖项在 Maven Central 上找不到。
• 传递受影响的插件：包含 104 个插件的列表，这些插件依赖于 351 个失败插件之一。

关于这些分析结果中出现的 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. 处理依赖项数据。这就是为我们提供 244 个依赖项，用于 206 个唯一的 <group>:<artifact> 的原因。
7. 考虑插件依赖于其中一个失败插件的插件。这会添加回 104 个插件。

讨论