java - 维护内部 Maven 存储库的技巧？

Question

我有兴趣维护 Maven 2 我的组织的存储库。有哪些有用的提示和陷阱。

在发布代码时，用户在设置从存储库下载或发布自己的工件到存储库的标准时应遵循哪些准则？你对这类事情有什么样的治理/规则？您在开发者指南/文档中包含了哪些相关内容？

更新:我们已经建立了 Nexus，并且对此非常满意 - 遵循了 Sal 的大部分指导方针，没有遇到任何问题。此外，我们通过 Hudson CI 服务器限制了部署访问和自动构建/部署快照工件。 Hudson 可以分析所有上游/下游项目的依赖关系，因此如果编译问题、测试失败或其他一些违规行为导致构建中断，则不会发生部署。不要在 Maven2/Maven3 中进行快照部署，因为元数据在两个版本之间发生了变化。 “仅 Hudson”快照部署策略将缓解这种情况。我们不使用发布插件，但围绕 Versions plugin 编写了一些管道。当要移动快照以释放时。我们还使用 m2eclipse，它似乎与 Nexus 配合得很好，因为从设置文件中它可以看到 Nexus 并且知道从那里索引工件信息以进行查找。 (尽管我不得不调整其中一些设置以使其完全索引我们的内部快照。)如果您有兴趣这样做，我还建议您将带有工件的源 jar 部署为标准做法。我们在 super POM 中进行配置。

我遇到了this Sonatype whitepaper其中详细介绍了采用/成熟度的不同阶段，每个阶段对 Maven 存储库管理器都有不同的使用目标。

Answer 1

我建议设置一个至少包含四个存储库的 nexus 服务器。我不会推荐 Artifact 。免费版的 nexus 非常适合不到 20 人、不到三个小组的开发团队。如果您有更多的用户，请帮自己一个忙并为 Sonatype 版本付费。 LDAP 集成是物有所值的。

1. 内部发布
2. 内部快照
3. 内部第 3 方，用于内部使用的来自外部来源的代码，或用于经认可的第 3 方版本。将 JDBC 驱动程序、javax.* 内容以及来自客户和合作伙伴的内容放在这里。
4. 外部代理所有常用来源(如 m2、codehaus 等)的通用代理

将 Nexus 配置为对内部存储库执行以下操作

1. 定期删除旧快照
2. 发布时删除快照
3. 构建索引文件。这也加快了本地构建速度

有一个通用的 settings.xml 文件，它使用这四个且仅这四个源。如果您需要在此之外进行自定义，请尝试保留设置的通用部分文件并使用配置文件来找出差异。不要让您的客户只是滚动他们自己的设置，否则您最终会得到构建在一台机器上而不是在任何其他机器上的代码。

为您的客户端提供一个通用代理。在 Nexus 中，您可以将一堆代理添加到通用 Maven 源(Apache、JBoss、Codehaus)，并将一个代理暴露给内部客户端.这使得从您的客户中添加和删除源变得更加容易。

不要在同一个存储库中混用内部和第 3 方工件。 Nexus 允许您通过 web gui 将 jars 添加到内部存储库。我推荐将 JDBC 驱动程序和其他外部代码添加到 3rd 方的方式。与大多数企业软件相比，用户界面非常好用。

定义一个通用父 POM，通过 distributionManagement 标签定义内部快照和发布仓库。我知道很多人告诉你不要这样做。虽然我坦率地承认这样做存在各种问题，但如果客户只构建版本和快照以部署到单个内部存储库，那么它就可以了。

如果您有一个管理不善的现有 Maven 存储库，请创建一个名为 Legacy 的第 5 个存储库并将整个存储库放在那里。设置一个 cron 任务，以便在旧文件一岁后从旧文件中删除它们。这给了每个人一年的时间来摆脱它并更新他们的 pom。

为内部工件建立一个易于遵守的命名约定。我更喜欢 Department.Function.Project 的 GroupID 和该 componentName 的 ArtifactId >。对于内部存储库，com/org/net 和公司名称可能无关紧要。如果公司更名，那就错了。销售、会计或库存部门更名的可能性要小得多。