Where is the best place to specify maven repositories, pom.xml or settings.xml?_问答_开发者

Where is the best place to specify required repositories for maven projects, pom.xml or settings.xml? What are the pros and cons of each location? What is best practice?

It seems to me that defining the repositories in the POM is better for a number of reasons:

Reproducibility: The dependent artifacts are coming from a known location that is explicitly declared in the POM. There is also less opportunity for a user's misconfigured repositories to cause problems.
Portability: This POM will build on anyone's machine with maven installed. There are no additional requirements on additional user configured repository settings.
Ease of use: It's easier for new developers to retrieve and build the project because there is less configuration to setup.

Perhaps a con is that if the location of the repository changes in the future, proxies need to be installed or patch releases of old software need to be released specifying the new repository locations (or .m2/settings.xml can always provide additional repositories as a last resort). However, this seems like a necessary ramification of good reproducibi开发者_StackOverflowlity and portability in release management rather than a con.

Any other thoughts?

Where is the best place to specify required repositories for maven projects, pom.xml or settings.xml? What are the pros and cons of each location? What is best practice?

I'd personally define the repositories required by a particular project in the project pom.xml because it keeps the build portable. The settings.xml file should be used for user specific or secret things only in my opinion. No really, asking the user to add repository locations, even if this is properly documented, somehow defeats one of maven's feature (transparent dependency handling) and I don't like this idea.

The only "good" use case I can think of for using settings.xml to deal with repositories is when you have a corporate repository and want Maven to use this repository instead of public ones. For example, to avoid connections to any public repository, you would declare the corporate repository as a mirror of all of them:

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

I'll give you three reasons why you should consider storing repository URLs in settings.xml instead of pom.xml:

spekdrum mentioned something that has actually happened to us:

If you have a corporate repo and you are building a project for a customer and you have to deliver the source code at the end you better configure the repos in settings.xml. You don't want your Artifactory (or similar) to be reached every time the project is built outside your office.

The guys at Sonatype recommend placing URLs in settings.xml.
If the dependency repository goes down (think java.net) you only have to correct the URL in one place. If you used pom.xml all previous releases are broken. You potentially have to commit a fixed pom.xml per release version.

Is configuring URLs in settings.xml more work than pom.xml? Absolutely.

Does it buy you more flexibility? Absolutely.

Here is what settings.xml should look like:

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

I always put URLs in the POM and passwords in settings.xml. If you put URLs in settings.xml, you require your users to update files on their local systems if your URL ever changes. If the URL is specified in your POM, you can change it and push a new release. URLs change more often than most can predict and lead to frustrated users when the build breaks.

Passwords are kept in settings.xml for obvious reasons. Passwords should never be kept in version control. You'll need passwords for mvn deploy functionality to deploy to remote repositories.