注意前置

注意，本文讲解的是针对我们原来所用的nexus2.14.5版本的升级配置流程，如果您的老私服版本并不是这个，那么请先参考这里：升级兼容性 – Repository Manager 2到3 (opens new window)。选定对应可升级版本之后，再阅读本文获取经验。

另外，虽然本文介绍了两种可行的方案，但是，我仍旧推荐使用HTTP下载的方式进行升级，至于原因是什么，请往下看就知道了。

---

那么书接上回。

可能大家还记得上篇最后发生了什么，就是com.third:google.guava:jar:14.0.1这个包下载失败，从而导致项目编译终止。我们也都知道，解决的办法就是手动下载对应的包，然后传到私服上去即可。

但是，总觉得很麻烦，因为在公司几年的项目积累下，可能会有不止1个，十个，甚至百个这样下载不下来的包。为了针对这个问题，我想过如下几个办法：

1，两种失败的尝试。

1，给服务配代理。

这种思路大概就是你不能下载某些包，无非就是这资源需要翻墙，那就让服务能上外网呗。

[root@nexus local]$curl cip.cc
IP    : 47.91.208.248
地址    : 中国  香港  阿里云
运营商    : 22.396428
 
数据二    : 香港 | 阿里云
 
数据三    : 中国香港香港 | 阿里云
 
URL    : http://www.cip.cc/47.91.208.248

然后编译测试拉取，发现仍旧不行。

2，直接迁移。

网上有不少方案是讲直接更改nexus里边的配置，然后让新服加载老的数据的，但这种不优雅的方式，经过我的测试之后，发现可行性并不是很大，尤其是在nexus2.x到3.x之间的升级之上。故而不推荐这种方式。

2，成功方式1–代理旧私服。

提示

这个思路应该是最妙的。我想，既然我们可以添加一个远程的proxy，为什么不能把老的私服作为一个远程proxy呢，虽然这种方案需要新老两个私服同时运作，但作为一种新老交接的情况，似乎也可以容忍。

说干就干，我又添加了一个proxy，将其中的地址定义为老私服的地址，配置如下：

• Proxy：改成老私服地址。
• Authentication：添加用户名密码。

这里配置完并保存之后，我们再去到group里边添加上：

这里上下有一个优先级，所以我们给它调整为第一位：

保存之后，回到项目中再次构建：

惊然发现，项目就此顺畅的构建成功了。去到私服里边看看：

看到了，是他，老泪纵横的，看到了这种奇妙的思路也成功了。

提示

不过，这种方法的问题在于，我这里只测试了一个项目的构建，也就是仅仅将此项目对应的依赖从老项目当中拉了过来，如果此时还只能让两个私服共存，但你不知道什么时候才真正的完全拉完，因此有点尴尬。

3，成功方式2–HTTP下载。

于是，这就引出了今天的第四种方案，那就是nexus内置的一种迁移方式：HTTP下载 (opens new window)。也就是，只需要对着nexus点点点，即可实现一劳永逸的搬迁，这个方案，着实令人欣喜。

接下来，不废话，直接进入正题。

1，老私服配置Upgrade:Agent。

如果想实现迁移，首先要配置 Upgrade:Agent ，这个配置比较简单，直接通过截图来展示：

• 1，点击Capabilities。
• 2，New一个新的。
• 3，选择Upgrade: Agent。
• 4，创建一个Access Token，用于远程连接。这里设为123456。

创建之后查看一下：

2，新私服配置连接。

新服安装以及登陆，这且按下不表，可以参考前边的文章，这里直接进入配置环节。

1，点击Capabilities，New一个新的。

2，选择Upgrade。

3，创建。

4，配置链接开始升级。

5，配置老私服地址。

将老私服地址填入，并将刚刚定义的token写入。

就在当我以为一切都是这么愉快欢乐得的时候，问题来了：

说升级时，与版本关系紧密。还给了个建议，说2.14.8版本的好像更容易升级。

ok，既此开始，我陷入了无尽的版本深渊当中，也正是自此开始，我开始关注升级过程中，版本的重要性。

首先我们老私服的版本是2.14.5，这个版本说实话在2.x界是并不低的，而我现在所用的新私服版本是3.12.1的，于是我首先尝试安装了3.1.0的进行升级，发现仍旧会有这样那样的报错。

直到，我在官方文档当中碰到了这么一篇文章：升级兼容性 – Repository Manager 2到3 (opens new window)。

就是遇到了这篇救命文章之后，这所有的问题，都不是问题了。

在文档当中有这样一个表格：

从表格当中，我看到了与公司老私服对应版本2.14.5可升级的3.7.1，也看到了如果想直接跳到3.12.1，则需要先将2.14.5升级为2.14.8，然后才能从2.14.8升级到3.12.1。

反正都是个升级，我最终选择了，在另一台测试机器上安装一个3.7.1版本的私服作为临时中转。

于是，安装，登陆，配置，说话间，就来到最关进的认证阶段：

此时此刻，看到绿色的success，不得不说，我眼含泪水，终于等到你。

剩下的就好办了，一路next即可。

不过这里稍微可以配置一下。

• Destination：选择我们创建的blob：maven-use。

• Method：这里边有三种类型，Hard link(文件系统硬链接)，Filesystem copy（文件系统复制），Download（HTTP下载）。

此三种类型区别，可以参考官网介绍：数据传输方法。 (opens new window)

此处我们选择默认的，就是我们用的HTTP下载的方式。

识别到了老私服里边的仓库，这里直接全选，吼吼。

万事已毕，只等一声令下：Begin。

历史瞬间，剪影留念。

接着，就可以看到迁移前的体检阶段：

检测已经结束，一共有59622项内容，点击继续即可同步。

看到这个界面，就是成功了：

当同步完成，我们可以在public里边看到这些从老私服同步过来的包。

然后把这个public加入到我们创建的group里边：

然后再将上回书中的项目进行构建，此时发现：

已经可以构建成功了，说明我们做的迁移工作，是生效了的。

当我看到成功的界面是，我止不住激动心情，去找到同事分享这种成就感以及喜悦！

4，两种成功的方式之总结。

上边列举了两种成功的方式，这两种方式的差别还是非常大的，我们来通过一个小小的数据来对比一下：

看了两个sonatype-work大小的对比，就能清晰了解到，在前边我们所担忧的问题，果不其然的在这里出现了，一个8G多，一个800多M，这两者之间的差距，恐怕就是我们需要让新老私服共存的时间差吧，于是乎，最终，我最推荐的方式还是HTTP下载的方式。

如果你想要使用最新版本的私服，那么可以先通过HTTP下载的方式从2.x升级到3.x，然后再直接将对应的sonatype-work复制到最新版本的私服当中，直接启动即可。

5，研究感言。

这是一个没有老师的自学，网上或多或少也有不少教程，有一些教程是帮助你的，有一些教程是坑害你的，这与教程本身无关，而与你遇上这些教程的缘分以及个人的悟性有关，总而言之，只有认真学习，勤思多练，才能在荒漠当中，走踏处一条明路。

6，参考链接。

• 1，https://help.sonatype.com/repomanager3/upgrading/data-transfer-methods#DataTransferMethods-HTTPDownloading
• 2，https://help.sonatype.com/repomanager3/upgrade-compatibility—repository-manager-2-to-3 (opens new window)
• 3，https://www.ilanni.com/?p=12366