将 3rd 方库安装到托管 Maven 存储库的最佳实践？

Question

假设您有一个项目正在使用 3rd 方库，例如 Google's Analytics Data API (gdata)，目前似乎没有部署到任何知名或流行的 Maven 公共存储库/索引中。这不是什么大问题，因为我可以将工件部署到本地托管的 Nexus 存储库中。

但是，由于尚未在公共存储库中为它设置标准，因此 Maven 社区中是否有任何最佳实践来说明我应该如何在我的 POM 中命名这个库的“坐标”？

例如，我应该在我的 POM 中将其称为

<dependency>
    <groupId>com.google</groupId>
    <artifactId>gdata-analytics</artifactId>
    <version>1.0</version>
</dependency>

或者有什么更好/更标准的方法让我想出artifactId？

（而且，为什么像谷歌这样的几十个库的提供者不努力将它们托管到主流的公共 Maven 存储库/索引中？这不是让人们更容易使用它们吗？从而推动采用？）

Answer 1

你所做的很合理。一些额外的点：

• 当 Maven 从 Nexus 获取工件时，该工件被命名为 artifactId-version。 GroupId 令人讨厌地被省略了。因此，当工件被移动时（例如，复制到 Web 应用程序中的 WEB-INF/lib 中），您的 jar 文件将显示为“gdata-analytics-1.0”。这通常不是问题。但是，如果工件名称很常见，例如“util”，您可能希望在 artifactId 中包含组信息，例如使用“com.google”的 groupId 和“com.google.gdata-analytics”。是的，重复很烦人，但它在文件系统和搜索中产生了最大的清晰度。我实际上遇到了一个问题，即两个不同的 groupId 都有一个“core-1.0” jar，并且在构建时复制到 lib 目录时一个覆盖了另一个。

  李>

• 我赞同 MattK 的建议，即将您的 Maven versionId 与工件通常已知的任何版本对齐。

• 如果您遵循 Dominic 的建议，在 groupId 前加上您自己的公司名称（例如 acme），可能会更容易利用 Nexus 的路由功能。它将确保内部工件的请求不会传播到 Maven Central 并最终出现在它们的日志中（如果您的 groupId 是“acme.secret.project”，这可能很重要！

Answer 2

我已经使用 Maven 大约一年了，从未遇到过“标准”命名约定。我通常会完全按照您的方式进行操作，尽管我会尝试使版本号尽可能接近“真实”版本号，以免在部署多个版本时造成混淆。

Answer 3

我倾向于在 groupId 前面加上我自己常用的 groupId。这清楚地表明这是我上传的东西，以防万一它泄露给整个世界。

Answer 4

许多 sourceforge 项目在 groupid 中使用项目的名称，例如：

GroupId net.sf.json-lib ArtifactId json-lib

这可能适用于 google 示例，因为有很多 google 工件。

请记住，您可以使用分类器标记来区分两个罐子 相同的版本，但为不同的目的而构建，例如不同的 JVM。

Answer 5

您可能会走运：Google 为他们的项目提供了自己的 Maven 存储库。看到这个页面：Instructions

我有一些专有的 Jar 文件，所以我必须在每个工作站上加载它们（我们还没有公司共享存储库）。我将它们放在 /lib 目录中的源代码树中（并不总是一个好主意），并添加了一个包含 mvn install-file 命令的小 .BAT 文件（或 .sh 脚本），以首先加载我本地机器的 repo我建造的时间。如果我必须更新这些 jar，我也会更新“load.bat”文件，然后重新运行它。在我的情况下，我不希望这种情况每年发生一次以上，也许更少。