JCenter 迁移指南 - 哈喽比特 - https://www.hellobit.com.cn

267次阅读 | 发布于3年以前

‍前言

JCenter 远程仓库已经宣布停止维护了，经过一段时间的实践和踩坑，现在由我来给大家讲讲 JCenter 停更带来的影响及分享解决的方案。

进入 Bintray 官网，就会发现有一个很明显的红色横幅，大致的意思是：注意所有 Bintray 服务将被弃用，您的帐户将在 2021 年 5 月 1 日被禁用，学习更多的知识。

点击学习更多，我们可以发现了 Bintray 官方对本次操作做出的解释，由于全是英文，为了方便大家，我直接翻译成中文给大家看：

官方主要讲了三点内容，分别是：- 解释为什么停止维护

停止维护的时间节点
常见一些问题的解答

为了节省大家时间，我对内容做了提炼精简，为大家简单解说一下：- Bintray 和 JCenter 因为挣不到钱，所以业务被砍掉了，需要开发者提前做一下迁移。

截止 2021 年 3 月 30 日之后不能上传任何库，2022 年 2 月 1 日之后不能下载任何库。
停止维护之后，Bintray 账户将被限制登录，Bintray 官网将不能被访问，所有数据在最后一天从服务器中被删除。

影响范围

先来谈谈这次事件带来的影响：影响范围很广，主要表现为 2022 年 2 月 1 日之后 Android Studio 将无法从 JCenter 仓库拉取任何代码库，统统都会拉取失败，间接导致项目无法编译通过。

这是创建新项目的远程仓库配置，默认只配置了 Google 和 JCenter，这时大家心里可能在想：JCenter 仓库挂掉了没事，反正还有 google 仓库呢。

但事实却是：Google 仓库是谷歌官方的远程仓库，只存放谷歌官方的一些框架，例如 AndroidX 相关的包都是放在这里的，暂时不对外开放，也就是说现在大家用的第三方框架基本都是放在 JCenter 仓库上，就问你一句方不方？慌不慌？

/ 解决方案 /

面对问题，我觉得只会慌是解决不了问题的，还是得多想想办法，而不是坐以待毙，我最近花了很多时间研究了这个问题，最后发现解决这个问题其实并不难，JCenter 仓库用不了，可以换成 JCenter 的镜像仓库。

在这里我推荐使用阿里云云效仓库和华为开源镜像站来解决这一问题，在项目根目录下的 build.gradle 文件中这样配置：

buildscript {
    repositories {
        // 阿里云云效仓库：https://maven.aliyun.com/mvn/guide
        maven { url 'https://maven.aliyun.com/repository/jcenter' }
        maven { url 'https://maven.aliyun.com/repository/google' }
        // 华为开源镜像：https://mirrors.huaweicloud.com
        maven { url 'https://repo.huaweicloud.com/repository/maven' }
        // JitPack 远程仓库：https://jitpack.io
        maven { url 'https://jitpack.io' }
        // MavenCentral 远程仓库：https://mvnrepository.com
        mavenCentral()
        google()
        jcenter()
    }
}

allprojects {
    repositories {
        maven { url 'https://maven.aliyun.com/repository/jcenter' }
        maven { url 'https://maven.aliyun.com/repository/google' }
        maven { url 'https://repo.huaweicloud.com/repository/maven' }
        maven { url 'https://jitpack.io' }
        mavenCentral()
        google()
        jcenter()
    }
}

这时大家心中可能有另外一个疑问，为什么 JCenter 仓库挂了，而它的镜像仓库却还能用呢？这个问题要从这个东西诞生的原因说起，由于 JCenter 是外国人开发的，用的是自然是国外的服务器，所以访问起来很慢，从这些地方拉代码自然也快不了，严重影响开发效率，所以国内就诞生了关于 JCenter 的镜像仓库，用于解决这一问题。

具体的实现原理是将 JCenter 仓库上的代码库拷贝一份放到国内的服务器的硬盘上面，这样我们再拉取代码库就会快很多，而对于 JCenter 停止维护的事件，其实就是停止外界对服务器的访问，而如果我们重新指向服务器地址，这样是不是就完美避开了访问 JCenter 服务器？从我的认知看来是没有问题的，大家对此也可以提出不同的意见。

迁移方案

上面主要是针对使用者的解决方案，假设我是开源库作者，那么该如何应对这个问题呢？

如果是开源库的作者，只能通过换远程仓库服务商来解决问题，不换的话现在代码库已经上传不了 JCenter，从而导致框架无法发布新的远程依赖。

现在除了 JCenter 方案，其实还有两个备选方案，mavenCentral 和 JitPack，这两个远程仓库也是比较常用，经过对比，我最终选择了 JitPack 作为新的代码库存放仓库，主要的原因也很简单，相比 mavenCentral，JitPack 的流程更简单，主要表现为不需要注册账号，不需要在项目 Gradle 中配置信息，只需要将代码库发布到 Github 即可，最后在 JitPack 构建一下就可以了。

现在由我来给大家演示一下具体的操作方式。

第一步：提交代码到 Github 上面（常规操作）

第二步：找到 Github 页面中的 Release 选项

第三步：创建一个新的 release 版本

第四步：填写好相关的信息

第五步：填写完之后点击Publish release按钮

第六步：打开 JitPack 官网 https://jitpack.io/

第七步：输入 Github 地址，并点击Look up按钮

第八步：选择刚刚创建的 10.5 的版本，点击右边的Get it按钮

第九步：等待构建完成，等转圈的图标变成文件的图标就说明已经完成

第十步：点击 Get it 按钮，这时会显示代码库远程依赖信息

至此上传代码库到 JitPack 仓库的流程已经讲完，有一点需要的是，我们需要在 Github 项目主页中提醒开发者加入：

否则会出现有些开发者拉取不到代码库的问题，这是因为 Studio 创建的工程默认只配置了 Google 仓库和 JCenter 仓库，默认并没有配置 JitPack 仓库。

另外告诉大家一个好消息，我个人的所有框架已如数迁移到 JitPack 仓库了，有使用到我写的框架的同学可以考虑找一个时间点，然后做一下统一升级和迁移。

友盟迁移

随着 Bintray 的逐渐关闭，有友盟远程依赖的项目也运行不起来了，编译时提示报错：


Unable to resolve dependency for ':umeng@previewUnitTest/compileClasspath': Could not download common-2.2.5.jar (com.umeng.umsdk:common:2.2.5)
Unable to resolve dependency for ':umeng@preview/compileClasspath': Could not download analytics-8.1.6.jar (com.umeng.umsdk:analytics:8.1.6)

然后我去官网看了一下，果然不出所料，这个不止是我一个人的问题，而是大家都会。

大家可以先看看友盟的公告：【公告】安卓SDK在线依赖库迁移，看情况是有救了，然后我按照友盟的提示去做了。公告链接：> https://info.umeng.com/detail?id=443&cateId=1

结果发现还是不行，不过我发现最下面有一段话：获取时必须为最新版的SDK，顿时我明白了什么，原来友盟只放了最新版本在 Maven 库上面，why？那我们这些用旧版本的用户怎么办？公告上面也没有写，友盟这工作做得不到位啊，请允许我打个差评。不过在我看来解决这个问题的方法有两种，大家可以根据自己的实际情况而定。

方法一：升级新版本，可以根据友盟发布的公告进行修改，只不过这种只能升级到最新版本，当然你要是对友盟的 Maven 库没有信心，可以考虑直接下载最新的 Jar 包进行离线依赖。

方法二：沿用旧版本，这块的话友盟没有给出解决方案，但是贸然升级版本必定存在一定的风险，假设测试同学没有空做测试，那么很容易就会出现问题，这个时候为了项目能正常运行，又能以最低的成本来做这件事，依赖原有的旧版本就很有必要了，那么旧版本的 Jar 包该从哪里找呢？我相信很多人第一反应是去 Bintray 官网的友盟仓库中找找看。

正当我高兴的时候，现实狠狠给我泼了一波冷水，我点击下载 common-2.2.5.jar，却发现结果是这个样子的。

顿时感觉被命运扼住了喉咙，难道就没有其他办法了吗？

答案其实有的，我小脑瓜忽然灵机一动：去 Github 找找看？

事实证明，只要思想不滑坡，办法总比困难多，你学废了吗？

至于两种方案要选择哪种，我觉得吧，在开发和测试同时都能空出人力来做时，可以优先考虑升级友盟 SDK 来解决问题，这样做还有另外一个好处，新版本的 SDK 肯定是修复了旧版本的某些 Bug，不如趁此机会提升一下应用的稳定性，但是如果没有时间做，也可以先考虑直接找旧版本的 Jar 包来解决问题，毕竟项目要能运行才是目前最最最重要的事情。