我相信 Sonatype 建议使用本地 Nexus 实例,尽管他们自己的研究表明(2015 年软件供应链状况报告)到 Maven Central 的流量中只有不到 5% 来自此类存储库。
回到这个问题,假设您在构建服务器(例如 Jenkins)和 Nexus 之间有一个本地 Nexus 实例和高带宽连接(至少数十 Gbps),那么我可以看到使用私有本地存储库的一些缺点,在事实上,我认为构建性能的下降是一个合理的权衡。
上面说,我们到底在权衡什么?我们接受了一个小的性能损失,我们可以 100% 肯定地知道,独立、干净的构建与我们的本地 Nexus 实例作为代理工作。
后者很重要,因为考虑构建服务器上的本地存储库(可能在 jenkins 的用户主目录中)具有未缓存在 Nexus 中的人工制品(如果您开始针对 Maven Central 构建,这并非不可能) . 这种不同步的情况不是最理想的,因为如果 Nexus 与 Central 的上游连接暂时关闭,可能会出现 Nexus 中的缓存 TTL 设置意味着构建失败的情况。
最后,为了增加权衡的好处,我今天花了几个小时在共享的 Jenkins 用户 .m2/repository 中获得了一个人工制品。当天早些时候,与 Central 的上游连接在本地上下波动了数小时(企业环境中的神秘问题)。最后,我删除了整个共享 jenkins 用户 .m2/repository 以便从本地 Nexus 中检索所有内容。
值得考虑使用本地 .m2/repository(在 jenkins 用户主目录中)构建以及使用私有本地存储库(快速和较慢构建)进行构建。然而,在我的情况下,我可能只在第一种情况下选择私有本地存储库 - 如果我通过专注于低悬的成果来优化构建(例如拆分多模块构建),我可能能够接受惩罚。