本文章已授权郭霖微信公众号转载
- 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/public' }
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/public' }
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 仓库了,有使用到我写的框架的同学可以考虑找一个时间点,然后做一下统一升级和迁移,点击此处可以直达 Github 地址。
友盟迁移
- 随着 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在线依赖库迁移,看情况是有救了,然后我按照友盟的提示去做了。
结果发现还是不行,不过我发现最下面有一段话:获取时必须为最新版的SDK,顿时我明白了什么,原来友盟只放了最新版本在 Maven 库上面,why?那我们这些用旧版本的用户怎么办?公告上面也没有写,友盟这工作做得不到位啊,请允许我打个差评。
不过在我看来解决这个问题的方法有两种,大家可以根据自己的实际情况而定。
方法一:升级新版本,可以根据友盟发布的公告进行修改,只不过这种只能升级到最新版本,当然你要是对友盟的 Maven 库没有信心,可以考虑直接下载最新的 Jar 包进行离线依赖。
方法二:沿用旧版本,这块的话友盟没有给出解决方案,但是贸然升级版本必定存在一定的风险,假设测试同学没有空做测试,那么很容易就会出现问题,这个时候为了项目能正常运行,又能以最低的成本来做这件事,依赖原有的旧版本就很有必要了,那么旧版本的 Jar 包该从哪里找呢?我相信很多人第一反应是去 Bintray 官网的友盟仓库中找找看。
- 正当我高兴的时候,现实狠狠给我泼了一波冷水,我点击下载 common-2.2.5.jar,却发现结果是这个样子的
顿时感觉被命运扼住了喉咙,难道就没有其他办法了吗?
答案其实有的,我小脑瓜忽然灵机一动:去 Github 找找看?
事实证明,只要思想不滑坡,办法总比困难多,你学废了吗?
至于两种方案要选择哪种,我觉得吧,在开发和测试同时都能空出人力来做时,可以优先考虑升级友盟 SDK 来解决问题,这样做还有另外一个好处,新版本的 SDK 肯定是修复了旧版本的某些 Bug,不如趁此机会提升一下应用的稳定性,但是如果没有时间做,也可以先考虑直接找旧版本的 Jar 包来解决问题,毕竟项目要能运行才是目前最最最重要的事情。
到此 JCenter 迁移指南已经全部讲完,感谢大家的观看,大家有什么问题欢迎在评论区指出。