由 Maven 构建

将工件上传到中央存储库的指南

为了让 Maven 用户能够利用项目生成的工件，您必须将它们部署到远程存储库。许多开源项目希望允许使用 Maven 构建项目的用户能够透明地访问其项目的工件。为了实现这一点，项目应将其工件部署到Central Repository。

要求

  1. 发布：只有发布可以上传到中央存储库，这意味着文件不会更改并且仅依赖于已发布并在存储库中可用的其他文件，
  2. 用于 IDE 查找的javadoc 和源代码，
  3. PGP签名，
  4. 最小 POM 信息：对中央存储库中的 POM 中的最小信息有一些要求，请参见此处，
  5. 坐标：为您的项目选择合适的坐标很重要。请参阅此处的指南，尤其是关于groupId 和域所有权的指南。

可以在此处找到更新的要求列表。

解释

有些人问“为什么我们需要 POM 中的所有这些信息来部署工件？” ，所以这里做一个小解释。

与工件一起部署的 POM 是使传递依赖关系在 Maven 中成为现实的过程的一部分。让传递依赖起作用的逻辑实际上并不难，问题在于获取数据。通过让所有 POM 可用于工件而成为可能的其他应用程序是巨大的，因此通过将它们放入中央存储库作为流程的一部分，我们为涉及对项目 POM 的统一访问的新想法打开了大门。

我们要求提供许可证，因为您的项目的许可证可能会在其生命周期内发生变化，我们正在尝试创建工具来帮助解决许可问题。例如，了解特定工件图的所有许可，我们可以制定一些策略来识别潜在的许可问题。

一个基本样本：

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>org.apache.maven</groupId>
  <artifactId>maven</artifactId>
  <version>2.0</version>
  <packaging>jar</packaging>

  <name>Maven core</name>
  <description>The maven main core project description</description>
  <url>http://maven.apache.org</url>

  <licenses>
    <license>
      <name>Apache License, Version 2.0</name>
      <url>http://www.apache.org/licenses/LICENSE-2.0.txt</url>
      <distribution>repo</distribution>
    </license>
  </licenses>

  <scm>
    <url>https://svn.apache.org/viewvc/maven</url>
  </scm>

  <dependencies>
    <dependency>
      <groupId>...</groupId>
      <artifactId>...</artifactId>
      <version>...</version>
    </dependency>
    ...
  </dependencies>

  <!--
  NOT RECOMMENDED: (see FAQ)
  <repositories></repositories>
  <pluginRepositories></pluginRepositories>
  -->
</project>

PGP 签名

当人们从中央存储库下载工件时，他们可能希望根据公钥服务器验证这些工件的 PGP 签名。如果没有签名，则用户无法保证他们正在下载原始工件。

为了提高中央存储库的质量，我们要求您为所有工件（除校验和之外的所有文件）提供 PGP 签名，并将您的公钥分发到像http://pgp.mit.edu这样的密钥服务器。阅读使用 PGP 签名了解更多信息。

常见问题和常见错误

  • 我有其他repositories或pluginRepositories在我的 POM 中列出，这是一个问题吗？

    目前，这不会阻止您的项目被包含，但我们强烈建议确保您的所有依赖项都包含在中央存储库中。如果您依赖于其中有垃圾或消失的粗略存储库，它只会为下游用户造成破坏。尝试将您的依赖关系保持在可靠的存储库（如 Central、Jboss 等）之间。

  • 由于许可证而无法分发的工件怎么办？

    在这种情况下，只需要该依赖项的 POM，列出可以从哪里下载依赖项。看一个例子。

  • 我有一个在 foo.com 开发的 foo 项目的补丁版本，我groupId应该使用什么？

    当您修补/修改第三方项目时，该修补版本将成为您的项目，因此应该groupId像您开发的任何项目一样在您的控制下分发，而不是在com.foo. 请参阅以上关于groupId.

  • 我的项目托管在 SourceForge 或 Github 等项目托管服务上，我应该使用什么作为 groupId？

    如果您的项目名称foo位于 SourceForge，则可以使用net.sf.foo. 如果你的用户名bar在 Github 上，你可以使用com.github.bar. 您还可以使用您控制的另一个反向域名。组 ID 不必反映项目主机。

将工件发布到中央存储库

批准的存储库托管

我们现在鼓励项目使用经批准的存储库托管位置，而不是为每个项目维护存储库 rsync 提要。

当前批准的存储库托管位置：

将为为 OSS 项目和其他大型项目存储库提供托管服务的 Forges 提供自动发布，这些存储库满足某些最低标准，例如验证上述 PGP 密钥和 pom 内容。如果您有兴趣成为获得批准的 Forge，请联系我们。

其他的项目

上传另一个项目的最简单方法是使用开源软件存储库托管 (OSSRH)，这是 Sonatype 为任何想要将其工件放入中央存储库的 OSS 项目提供的经批准的存储库。

解释

在 2010 年 1 月之前，让每个项目维护自己的存储库并通过 rsync 到中央存储库是首选过程。但是，我们不再接受每个项目的 rsync 请求。

随着时间的推移，我们了解到这个过程是不可扩展的。许多正在同步的项目很少发布，但我们必须每天多次访问数百台服务器，以寻找不会改变的工件。此外，目前还没有很好的机制来验证通过 rsync 传入的数据，这会导致影响每个人的不良元数据。

将项目聚合到更大的源中使我们能够更快、更频繁地同步，并确保这些位置执行足够的检查可以提高每个人的元数据质量。