【问题标题】:Where is the best place to specify maven repositories, pom.xml or settings.xml?指定 maven 存储库、pom.xml 或 settings.xml 的最佳位置在哪里?
【发布时间】:2011-01-14 14:17:16
【问题描述】:

为 maven 项目指定所需存储库的最佳位置在哪里,pom.xmlsettings.xml?每个位置的优缺点是什么?最佳做法是什么?

在我看来,在 POM 中定义存储库更好,原因有很多:

  • 可重现性:相关工件来自 POM 中明确声明的已知位置。用户配置错误的存储库导致问题的可能性也较小。
  • 可移植性:此 POM 将构建在任何安装了 maven 的机器上。对其他用户配置的存储库设置没有其他要求。
  • 易于使用:新开发人员可以更轻松地检索和构建项目,因为需要设置的配置更少。

也许一个缺点是,如果存储库的位置在未来发生变化,则需要安装代理或发布旧软件的补丁版本,指定新的存储库位置(或者.m2/settings.xml 总是可以提供额外的存储库作为最后的手段)。然而,这似乎是发布管理中良好的可重复性和可移植性的必要分支,而不是一个缺点。

还有其他想法吗?

【问题讨论】:

  • 如果 repo 位置发生变化,您只需更新 pom 并确保每个人都刷新他们的本地副本。
  • 正确,但旧版本可能已作为发行版发布(例如:zip、tar.gz)。可重复性的一个很好的好处是您可以采用任何发行版/版本,以任何原因应用补丁,并且保证您获得确切的功能发行版以及您的补丁,仅此而已。
  • 我的观点与@jnorris 完全一致,但 Sonatype 提供了一些关于将 URL 保留在分布式 POM 文件之外的要点(可能已经过时?):blog.sonatype.com/2009/02/…

标签: maven-2


【解决方案1】:

为 maven 项目、pom.xml 或 settings.xml 指定所需存储库的最佳位置在哪里?每个位置的优缺点是什么?最佳做法是什么?

我个人会在项目pom.xml 中定义特定项目所需的存储库,因为它使构建保持可移植性。在我看来,settings.xml 文件应该仅用于用户特定或秘密的事情。不是真的,要求用户添加存储库位置,即使这已正确记录,以某种方式破坏了 maven 的功能之一(透明依赖处理),我不喜欢这个想法。

我能想到的使用settings.xml 处理存储库的唯一“好”用例是当您有一个公司存储库并希望 Maven 使用这个存储库而不是公共存储库时。例如,为了避免连接到任何公共存储库,您可以将公司存储库声明为所有公共存储库的镜像:

<settings>
  ...
  <mirrors>
    <mirror>
      <id>proxy-of-entire-earth</id>
      <mirrorOf>*</mirrorOf>
      <name>Maven Repository Manager running on repo.mycompany.com</name>
      <url>http://repo.mycompany.com/proxy</url>
    </mirror>
  </mirrors>
  ...
</settings>

【讨论】:

  • +1。这清除了我自己在解决这个问题时所想的“假设”。 1)如果镜像“消失”并且您需要提供一个新镜像(如果项目未维护并且您希望保持源代码树的原始状态)怎么办?在 settings.xml 中设置镜像 2) 如果您只想在某些环境中使用私有本地 repot 怎么办?按照您的建议,在 settings.xml 中使用通配符镜像。
  • FWIW,此信息现在也在 Maven 文档中 maven.apache.org/guides/mini/…
  • 如果您有一个公司仓库并且您正在为客户构建一个项目并且您必须在最后交付源代码,您最好在 settings.xml 中配置仓库。您不希望每次在您的办公室外构建项目时都可以访问您的 Artifactory(或类似设备)。
【解决方案2】:

我总是将 URL 放在 POM 中,将密码放在 settings.xml 中。如果您将 URL 放在 settings.xml 中,则如果您的 URL 发生更改,您将要求您的用户更新其本地系统上的文件。如果在您的 POM 中指定了 URL,您可以更改它并推送新版本。 URL 的变化比大多数人预测的要频繁,并且在构建中断时会导致用户沮丧。

出于显而易见的原因,密码保存在 settings.xml 中。密码永远不应该保存在版本控制中。您需要 mvn deploy 功能的密码才能部署到远程存储库。

【讨论】:

【解决方案3】:

我将给你三个理由,为什么你应该考虑将存储库 URL 存储在 settings.xml 而不是 pom.xml

  1. spekdrum 提到了一些实际发生在我们身上的事情:

如果您有一个公司存储库并且您正在为客户构建一个项目并且您必须在最后交付源代码,那么您最好在 settings.xml 中配置存储库。您不希望每次在您的办公室外构建项目时都可以访问您的 Artifactory(或类似设备)。

  1. Sonatype recommend 的家伙将 URL 放入 settings.xml

  2. 如果依赖库出现故障(想想java.net),您只需在一处更正 URL。如果您使用pom.xml,则所有以前的版本都已损坏。您可能必须为每个发行版本提交一个固定的pom.xml

settings.xml 中配置 URL 是否比 pom.xml 更有效?绝对的。

它会给您带来更多的灵活性吗?绝对的。

settings.xml 应该是这样的:

<settings>
    <profiles>
        <profile>
            <id>mycompany-servers</id>
            <repositories>
                <repository>
                    <id>mycompany-release</id>
                    <url>https://mycompany.com/release/</url>
                    <snapshots>
                        <enabled>false</enabled>
                    </snapshots>
                </repository>
                <repository>
                    <id>mycompany-snapshot</id>
                    <url>https://mycompany.com/snapshot/</url>
                    <releases>
                        <enabled>false</enabled>
                    </releases>
                </repository>
            </repositories>
        </profile>
    </profiles>
    <activeProfiles>
        <activeProfile>mycompany-servers</activeProfile>
    </activeProfiles>
    <servers>
        <server>
            <id>mycompany-release</id>
            <username>your-username</username>
            <password>your-api-key</password>
        </server>
        <server>
             <id>mycompany-snapshot</id>
             <username>your-username</username>
             <password>your-api-key</password>
        </server>
    </servers>
</settings>

【讨论】:

    猜你喜欢
    • 2013-01-17
    • 2011-04-17
    • 1970-01-01
    • 1970-01-01
    • 2020-12-11
    • 1970-01-01
    • 2013-02-12
    • 1970-01-01
    相关资源
    最近更新 更多