历史工作经历中，我已处理过两次将 nexus 从 2.x 升级到 3.x 的操作，这两次操作，都是参考的 maven 私服 nexus2-14-5 迁移到 nexus3-7-1 (opens new window) 这篇文章，按照文章记录的步骤，总体迁移还都是比较顺利的。

# 升级失败

升级过程中唯一遇到过的问题是，在同步的过程中，遇到过一个报错信息：Cannot execute query "SELECT * FROM quartz_trigger WHERE state IN [ ?,?,? ]": low heap memory，不知道这个错误信息是不是真正的表象，总之使用默认配置启动新的 nexus 升级过程中就会遇到这样的问题，解决的方案是，你的新 nexus 主机配置最好不低于 4C8G，然后调整内存大小：

$ cat bin/nexus.vmoptions

-Xms4096M
-Xmx4096M
-XX:MaxDirectMemorySize=6G

重启之后，再次重复升级的配置步骤，就能够成功同步了。

# 仓库地址变化

升级完成之后，nexus2 与 nexus3 对同一仓库的访问地址是有变化的，大概变化如下：

nexus2
	http://nexus2.eryajf.net/nexus/content/groups/public
nexus3
	http://nexus3.eryajf.net/repository/public/

稍微拆解一下两者的命名规范：

• nexus2
  • /nexus : 这是 nexus2 启动的时候，在配置中固定了 path。
  • /content ：类似 nexus3 中的 repository，是一个拼接在主 URL 之后的固定标识。
  • /groups ：用于表示这是一个 group 类型的仓库。如果是 host 或 proxy 类型，则为 repositories。
  • /public ：这一层才是仓库真正的名字。
• nexux3 - 默认启动的时候，没有带 /nexus。 - /repository ：对标 nexus2 中的 /content，这是 nexus3 中的固定标识。 - /public ：这一层才是仓库真正的名字。 可见在 nexus3 中对仓库命名进行了一些改变，改变了主固定标识，并去掉了 /groups 这一层的标识。

了解到了这个区别之后，在遇到升级之后的使用问题时就能清楚地定位到问题原因了。

# maven 打包

如果你的公司统一使用 maven 进行打包构建，那么你只需要在打包的机器上，在 maven 的 settings.xml 中将原来的 http://nexus2.eryajf.net/nexus/content/groups/public 改为 http://nexus3.eryajf.net/repository/public/ 即可，这个时候项目打包拉取依赖是不会受到任何影响的，但有一个需要注意的点在于：这个更改你也同时需要同步给开发者，让他们把自己本地指向原来的地址也一并改掉，否则将会以 nexus2 风格的 URL 在 nexus3 中检索依赖，肯定就会遇到找不到包的错误了。

# gradle 打包

gradle 打包风格的项目，通常私服地址的配置在每个项目根目录下的 build.gradle 文件中配置，这个时候要想改掉指向私服的 URL，可能就不是一个轻松的工作了，官方也提供了一个 nexus3 兼容 nexus2 命名风格的参数，从而让你在升级了 nexus 之后，不需要更改原来的配置，就可以使用新的版本：

$ cat etc/nexus-default.properties
### 文件中其他配置这里不陈列了

# 将访问URL后边的nexus配置上
nexus-context-path=/nexus

# 添加该配置，兼容 nexus2 的 URL 规范
org.sonatype.nexus.repository.httpbridge.internal.HttpBridgeModule.legacy=true

添加了配置之后，重启 nexus3 服务，这个时候，项目中仍旧使用 nexus2 风格的地址，但并不会影响拉包构建。

参考链接：migrating NXRM2 to NXRM3 automatically enables legacy content URLs (opens new window)