Hudson 提供了让 Maven 构建作业使用私有本地存储库的选项，或者使用 Maven 安装中的通用存储库，即与其他构建作业共享的一个。我觉得我们的构建应该使用私有的本地存储库来确保它们是干净的构建。但是，这会导致性能问题，特别是在为每个作业下载所有依赖项的带宽方面——我们还将作业配置为从干净的“工作区”开始，这似乎会破坏私有 maven 存储库以及其余部分建造空间。
对于日常的持续集成构建，为每个构建作业选择是否使用私有本地 maven 存储库的优缺点是什么？与其他工作共享本地存储库有什么大不了的吗？
【问题讨论】：
解释 jenkins 文档，您将使用 private Maven repository if
- 您最终导致构建错误地成功，只是因为您在本地存储库中拥有所有依赖项，尽管事实上 POM 中的任何存储库都可能没有它们。
- 您遇到了有关让并发 Maven 进程尝试使用同一本地存储库的问题。
还有
使用此选项时，请考虑设置一个 Maven 工件管理器 这样您就不必经常访问远程 Maven 存储库。
您还可以探索您的scm's clean option（而不是清理工作区）以避免此存储库被核爆。
【讨论】：
我相信 Sonatype 建议使用本地 Nexus 实例，尽管他们自己的研究表明（2015 年软件供应链状况报告）只有不到 5% 的 Maven Central 流量来自此类存储库。
回到这个问题，假设您在构建服务器（例如 Jenkins）和 Nexus 之间有一个本地 Nexus 实例和高带宽连接（至少数十 Gbps），那么我可以看到使用私有本地的一些缺点repo，事实上我认为构建性能的下降是一个合理的权衡。
上面说了，我们到底在权衡什么？我们接受了一个小的性能损失，我们可以 100% 肯定地知道，使用我们的本地 Nexus 实例作为代理工作的独立、干净的构建。
后者很重要，因为考虑构建服务器上的本地存储库（可能在 jenkins 的用户主目录中）具有未缓存在 Nexus 中的人工制品（如果您开始构建时，这并非不可能） Maven 中心）。这种不同步的情况不是最理想的，因为如果 Nexus 与 Central 的上游连接暂时中断，可能会出现 Nexus 中的缓存 TTL 设置意味着构建失败的情况。
最后，为了增加权衡的好处，我今天花了几个小时在共享的 Jenkins 用户 .m2/repository 中获得了一个人工制品。当天早些时候，与 Central 的上游连接在本地上下了几个小时（企业环境中的神秘问题）。最后，我删除了整个 jenkins 共享用户 .m2/repository，以便从本地 Nexus 中检索所有内容。
值得考虑使用本地 .m2/repository（在 jenkins 用户主目录中）构建以及使用私有本地存储库（快速和较慢构建）进行构建。但是，在我的情况下，我可能只在第一种情况下选择私有本地存储库 - 如果我通过专注于容易实现的成果（例如拆分多模块构建）来优化构建，我可能能够接受惩罚。
【讨论】：