我为什么要对 Sonatype 说再见

发表于 分类于 Disqus：

很久没有写博客了，一直忙于自己手上的各种项目。今天趁着 Sonatype 的问题，我来随便写一篇碎碎念。

起因

让我们先来说说这次事件的起因。老实说，我对 s01.oss.sonatype.org 的意见已经由来已久了。在此之前，我一直保持比较克制的心态去看待并处理这件事情。

UI 反人类，加载慢不说，还时不时加载错误。很难让人相信这是一个 2023 年还被开源开发者广泛使用（也没其他地方可去）的基建。

说了那么多，那么它真的不可替代吗？事实上，从某种角度来说确实是的。

关于 Gradle 的小 tips

我这里分享一个小 tips 给大家，顺便来讲讲为什么它是”不可替代“的。

这里我们会使用这个项目来举例：gradle-project-initializer-template

相信在 2023 年，使用 Gradle 的朋友对 settings.gradle.kts 和 pluginManagement 不再陌生了。

一般来说我们需要在顶层的 settings.gradle.kts 中添加以下代码：

1
2
3
4
5
6
pluginManagement {
    repositories {
        mavenCentral()
        gradlePluginPortal()
    }
}

才能使 Composite Build 的模块正常工作，不然 Gradle 会报错说找不到依赖。这里举个简单的报错例子。

以下是完全删除整个 pluginManagement 代码块所出现的报错：

1
2
3
4
5
6
7
8
9
10
11
A problem occurred configuring root project 'gpi-root'.
> Could not determine the dependencies of null.
   > Could not resolve all task dependencies for configuration ':classpath'.
      > Could not find me.omico.consensus.api:me.omico.consensus.api.gradle.plugin:0.3.0.
        Searched in the following locations:
          - https://plugins.gradle.org/m2/me/omico/consensus/api/me.omico.consensus.api.gradle.plugin/0.3.0/me.omico.consensus.api.gradle.plugin-0.3.0.pom
        Required by:
            project : > project :project

Possible solution:
 - Declare repository providing the artifact, see the documentation at https://docs.gradle.org/current/userguide/declaring_repositories.html

好的，现在我们知道当我们什么仓库都不声明的时候 Gradle 会”自作主张“的查找自家的仓库，也就是 gradlePluginPortal()。

那么，我们把这个 Gradle 插件所在的仓库添加进去会发生什么事情呢？

1
2
3
4
5
pluginManagement {
    repositories {
        maven(url = "https://maven.omico.me")
    }
}

我们可以很惊奇的发现，这项目还是跑不通。这是为什么呢？

1
2
3
4
5
6
7
8
9
10
11
A problem occurred configuring root project 'gpi-root'.
> Could not determine the dependencies of null.
   > Could not resolve all task dependencies for configuration ':classpath'.
      > Could not find com.diffplug.spotless:com.diffplug.spotless.gradle.plugin:6.20.0.
        Searched in the following locations:
          - https://maven.omico.me/com/diffplug/spotless/com.diffplug.spotless.gradle.plugin/6.20.0/com.diffplug.spotless.gradle.plugin-6.20.0.pom
        Required by:
            project : > project :project

Possible solution:
 - Declare repository providing the artifact, see the documentation at https://docs.gradle.org/current/userguide/declaring_repositories.html

看起来之前的 gradlePluginPortal() 不再被 Gradle ”自作主张“的添加了。 那么，我们它添加进去再看看。

哦，这次终于行了。

但这里还有一个坑需要注意哦，假如插件依赖的库在 gradlePluginPortal() 中不存在，比如说出现在 mavenCentral() 中。 那么你的项目还是会继续报错，直到你添加了 mavenCentral()。

更好玩的事情来了，如果你使用到的 Gradle 插件只依赖 gradlePluginPortal() 和 mavenCentral()，那么你什么都不需要声明项目依旧能正常运行。

这就是为什么我说 Sonatype 是不可替代的，因为在上述某些情况下，你可以少写几行 Gradle 配置代码。（笑~）

解决的办法

除去上面说的所谓的”不可替代“性，那么我们有什么办法快速解决这个问题呢？答案当然是有的！

我们先列举一下可选的方法，以及一些为什么我没用使用那种方法的理由。

使用本地仓库

本地仓库的优点是快，自己可以胡搞瞎搞。缺点是不方便，他人无法使用。这显然不符合我的需求，我是想把插件发布出去让他人使用的。

使用 JitPack

我仍然记得这个这个项目最早仅仅只是一个个人项目，并且出现过各种诡异的问题。这使我并不想像遇到 Déjà vu 一样再次走一遍老路。毫无疑问，这是从一个地狱逃离到另一个地狱。（谜之声：但你现在使用的方法就不会是地狱了吗？看来只能由时间来证明了。笑~）

使用 GitHub Packages

这个是现代的解决方案了。各方面都很完善，但是有一点阻止了我想要使用它 —— 它获取公开的依赖也需要访问令牌，这一点我非常不能接受，相信能整出这种操作就是为了收集数据。

使用 GitHub Pages

这个方法我最早在 rovo89 的 XposedBridge 中看到的。这个方法的优点是简单粗暴，你有100%的自主性，缺点是，想要用得舒服，你需要优化和规范发布流程，并且写一些小工具之类的。具体的实现细节，希望我能不咕咕，在以后发布的文章中我再细讲吧~

结语

说这说那，还是希望大家能再移步看看我在我的 Maven 仓库的 README 中所说的话吧~

总之，Sonatype Fuck You！