Maven 2 指定maven存储库、pom.xml或settings.xml的最佳位置在哪里？

哪里是指定maven项目所需存储库的最佳位置，

pom.xml

或

settings.xml

？每个位置的优缺点是什么？什么是最佳实践

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

• 再现性：依赖工件来自POM中明确声明的已知位置。用户错误配置的存储库导致问题的机会也较少
• 可移植性：此POM将构建在任何安装了maven的机器上。对其他用户配置的存储库设置没有其他要求
• 易用性：新开发人员更容易检索和构建项目，因为要设置的配置更少

也许一个缺点是，如果存储库的位置将来发生变化，则需要安装代理或发布旧软件的补丁版本，指定新的存储库位置（或

.m2/settings.xml

始终可以提供其他存储库作为最后手段）。然而，这似乎是发布管理中良好的可复制性和可移植性的必然结果，而不是一个缺点

还有其他想法吗

指定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>

...
整个地球的代理
*
在repo.mycompany.com上运行的Maven存储库管理器
http://repo.mycompany.com/proxy
...

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

---

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

> P>我将给出三个理由，您应该考虑在“代码>设置”中存储库URL。XML<代码>而不是<代码> POM.XML<代码>：

提到了发生在我们身上的事情：

---

如果您有一个公司回购协议，并且您正在为客户构建一个项目，并且最终必须交付源代码，那么您最好在settings.xml中配置回购协议。您不希望每次在您的办公室之外构建项目时都能访问您的人工制品（或类似产品）

Sonatype的人在

settings.xml

中放置URL

如果依赖项存储库关闭（想想

java.net

），您只需在一个地方更正URL。如果您使用了

pom.xml

，所有以前的版本都将被破坏。您可能必须为每个发布版本提交一个固定的

pom.xml

在

settings.xml

中配置URL比在

pom.xml

中配置URL的工作量更大吗？当然

这能给你带来更多的灵活性吗？当然

下面是

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>

mycompany服务器
mycompany发布
https://mycompany.com/release/
假的
mycompany快照
https://mycompany.com/snapshot/
假的
mycompany服务器
mycompany发布
您的用户名
您的api密钥
mycompany快照
您的用户名
您的api密钥

如果回购位置发生变化，您只需更新pom并确保每个人都刷新其本地副本。没错，但较旧版本可能已作为发行版发布（例如：zip、tar.gz）。重复性的一个很好的好处是，你可以采取任何发行版/版本，应用补丁的任何原因，你保证得到确切的功能分布加上你的补丁，没有别的。我的观点正好反映了JordRIS，但Sonatype提供了一些要点来考虑（也许过时了？）关于防止URL进入分布式POM文件：+1。这澄清了我自己在思考这个问题时所想到的“如果”的问题。1） 如果镜像“消失”，您需要提供一个新镜像（如果项目没有维护，您希望保持源树原始），该怎么办？在settings.xml 2中设置镜像2）如果您只想在某些环境中使用私有本地repot怎么办？按照您的建议，在settings.xml中使用通配符镜像。FWIW，如果您有公司回购协议，并且正在构建