为什么把你的仓库放进pom文件是一个坏主意

译自:http://blog.sonatype.com/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/
我经常得到这个问题，现在是时候写下我对答案的想法，这样我就可以不再重复自己了。 这是一个问题：

我是否应该将这些网址放到我的存储库或我的设置中？

简短的答案是：settings。

长的答案是：it depends。

这里有两种情况需要考虑。 企业软件（通常不是外部发布）和公共软件。 先让企业软件。 继续阅读这篇文章，了解这两种情况的完整说明。

企业

在企业场景中，您通常需要像Nexus那样在第一线上安装一个存储库管理器。它将代理所有外部存储库并托管您的内部存储库。

当Maven查找工件时，它沿着POM和设置中定义的存储库列表走下去，直到找到它想要的东西。如果您将资源库管理器定义为POM中的存储库，那么当存储库管理器中找不到工件时，Maven仍然会回退到内置的中央资源库。

一个可能的解决方案是重载“中央”存储库ID，并指向您的存储库管理器。这可以工作，但你会想在你的企业中做到这一点，所以你不需要在每个项目中定义它。一旦你超负荷“中心”，你有一个“Catch-22”。在一个干净的环境中，您需要知道存储库的哪个位置才能找到父POM，以告诉您存储库在哪里。无论如何，你最终必须在你的设置中定义这个存储库来引导。

简单地重新定义中央还有其他一些问题。具体而言，它不会重定向可能在其他包含传递的POM中定义的存储库。这会导致一些问题：首先，它会减慢你的构建，因为Maven会去找所有寻找工件的外部存储库…甚至可能是你内部的那些永远不会被发现的东西。其次，这意味着可能会为一个开发人员而不是另一个人开发。第三，它意味着作为一个组织，你不知道你的文物来自哪里。

作为一个组织，您通常会希望您的所有开发人员使用相同的一组存储库来构建它们，并通过受控机制来发出所有请求。在您的设置中使用mirrorOf *条目来最好地完成此操作，以将所有查找请求重定向到您的存储库管理器。在POM中定义镜像是不可能的。请参阅Nexus Book的这一部分，了解什么是好的设置。

考虑到所有这些事情，你可以看到，在你的poms中定义仓库对你来说并不是很有帮助，而且一般都会阻碍你。

这一切都假定你的工件不是外部消耗的。如果是，那么你也属于下一个类别。 （它们不是相互排斥的）

开源项目

如果您正在发布您的软件，而其他人将检查并构建它，那么还有更多要考虑的要点。如果您的所有依赖关系在中央存储库中都可用，那么您没有其他任何操作。但是，如果您的工件存在于您的存储库中（请考虑您的父级POM的快照）或其他第三方回购，那么开发人员将很难构建您的源代码。只有在这种情况下才能将库条目添加到您的POM中。但是，有一些副作用应该注意：

您定义的条目将被永久烧录到您发布的POM中。这意味着，如果网址改变了，那么任何使用您的POM的人都将面临这些破损的网址，并且必须手动追踪新网址。
这些条目中的每一条最终都会在消费者的构建中结束，因为Maven需要检查所有缺失的依赖关系。 Maven目前无法知道何时引入一个存储库，哪个依赖关系应该在那里找到（而且当你考虑传递性时，它会变得更糟）。
如果构建的产品是一个工具（如Nexus）而不是用作依赖项的组件，那么将该库添加到POM是相当安全的。在这种情况下，其他人将不太可能直接依赖于其他构建中的工件，并且上述问题已被取消，因为假定新源将具有正确的存储库URL。

如果您正在发布将被其他人使用的罐子，那么您应该考虑将其同步到中央存储库。这意味着，无论您的存储库或URL发生什么情况，它们都将始终面向所有用户，并且您不会意外地将新的存储库引入到其构建中。由于这个原因，中央将最终拒绝带有存储库元素的POM。

小结

总而言之，如果您想要在内部具有可重复的构建和对组织的良好控制，请使用存储库管理器，并在每个人的settings.xml中使用mirrorOf条目指向该URL。

如果你公开自己的源代码并想让其他人轻松构建，那么考虑在你的POM中添加一个存储库条目，但是不要轻易选择一个URL，长期考虑，并且使用一个总是处于下面的URL 你的控制。 如果您的网址必须改变，请确保始终能够跟踪404s并编写相应的mod_rewrite规则，以确保将来的版本能够找到合适的工件。