先总结一下吧！

pom文件：repositories配置的是私服地址，pluginRepositories配置的私服插件地址。

setting文件：profile配置的是全局私服地址和插件中心地址，mirror配置的是中央仓库的位置，当私服中找不到的时候就可以去中央仓库中去寻找，如果把中央仓库换成阿里云的就会快很多。

Maven中央仓库:


安装好Maven之后，我们可以建立一个简单的项目，配置一些简单的依赖，然后运行mvn clean install，项目就构建好了。我们没有手工的去下载任何jar文件，这一切都是因为Maven中央仓库的存在，当Maven在本地仓库找不到需要的jar文件时，它会查找远程仓库，而一个原始的Maven安装就自带了一个远程仓库——Maven中央仓库。maven安装目录下的：/lib/maven-model-builder-${version}.jar中



打开该文件，能找到超级POM：\org\apache\maven\model\pom-4.0.0.xml ，它是所有Maven POM的父POM，所有Maven项目继承该配置，你可以在这个POM中发现如下配置：



1.repositories配置


中央仓库的id为central，远程url地址为http://repo.maven.apache.org/maven2，它关闭了snapshot版本构件下载的支持。

<repositories>
    <repository> 

      <id>central</id> 

      <name>Central Repository</name> 

      <url>https://repo.maven.apache.org/maven2</url> 

      <layout>default</layout> 

      <snapshots> 

        <enabled>false</enabled> 

      </snapshots> 

    </repository> 

  </repositories>


如果我们在项目的pom文件里面去配置这样的属性，那么它将覆盖默认的中央仓库。

我们先看一下<repositories>的配置，你可以在它下面添加多个<repository> ，每个<repository>都有它唯一的ID，一个描述性的name，以及最重要的，远程仓库的url。

此外，<releases><enabled>true</enabled></releases>告诉Maven可以从这个仓库下载releases（发布）版本的构件，

而<snapshots><enabled>false</enabled></snapshots>告诉Maven不要从这个仓库下载snapshot（测试）版本的构件。禁止从公共仓库下载snapshot构件是推荐的做法，因为这些构件不稳定，且不受你控制，你应该避免使用。当然，如果你想使用局域网内组织内部的仓库，你可以激活snapshot的支持。

2.pluginRepositories配置

注意这个之前一直不理解：仔细一看突然明白了。repositories配置是远程仓库的位置，pluginRepositories配置的远程插件下载位置。

至于<pluginRepositories>，这是配置Maven从什么地方下载插件构件（Maven的所有实际行为都由其插件完成）。该元素的内部配置和<repository>完全一样，不再解释。 


<pluginRepositories>
    <pluginRepository>
      <id>central</id>
      <name>Central Repository</name>
      <url>https://repo.maven.apache.org/maven2</url>
      <layout>default</layout>
      <snapshots>
        <enabled>false</enabled>
      </snapshots>
      <releases>
        <updatePolicy>never</updatePolicy>
      </releases>
    </pluginRepository>  </pluginRepositories>



3.profile

前面介绍的主要是针对单个项目来讲，如果公司需要重复用到上面的配置可以用下面的方法解决。

在settings.xml中配置远程仓库

我们知道了如何在POM中配置远程仓库，但考虑这样的情况：在一个公司内部，同时进行这3个项目，而且以后随着这几个项目的结束，越来越多的项目会开始；同时，公司内部建立一个Maven仓库。我们统一为所有这些项目配置该仓库，于是不得不为每个项目提供同样的配置。问题出现了，这是重复 ！


其实我们可以做到只配置一次，在哪里配置呢？就是settings.xml。


不过事情没有那么简单，不是简单的将POM中的<repositories>及<pluginRepositories>元素复制到settings.xml中就可以，setting.xml不直接支持 这两个元素。但我们还是有一个并不复杂的解决方案，就是利用profile，如下：

 

1. <settings>  
2.   ...  
3. <profiles>  
4. <profile>  
5. <id>dev</id>  
6. <!-- repositories and pluginRepositories here-->  
7. repositories 和pluginRepositories -->  
8. </profile>  
9. </profiles>  
10. <activeProfiles>  
11. <activeProfile>dev</activeProfile>  
12. </activeProfiles>  
13.   ...  
14. </settings>

这里我们定义一个id为dev的profile，将所有repositories以及pluginRepositories元素放到这个profile中，然后，使用<activeProfiles>元素自动激活该profile。这样，你就不用再为每个POM重复配置仓库。

使用profile为settings.xml添加仓库提供了一种用户全局范围的仓库配置。

4.mirror配置

这个的意思是前面配置的私服地址如果找不到的话，回去中央仓库寻找，在这配置的是中央仓库的位置。

使用镜像
如果你的地理位置附近有一个速度更快的central镜像，或者你想覆盖central仓库配置，或者你想为所有POM使用唯一的一个远程仓库（这个远程仓库代理的所有必要的其它仓库），你可以使用settings.xml中的mirror配置。

以下的mirror配置用maven.net.cn覆盖了Maven自带的central


5.dependencyManagement配置

简单来说，maven项目多模块情况时作依赖管理控制的，如果子项目中写了依赖，就用子项目中的依赖。

dependencies:依赖,jar包管理。

dependency：具体的依赖项。


dependencyManagement：依赖,jar包管理。


dependencyManagement和dependencies区别：


 1)dependencies:自动引入声明在dependencies里的所有依赖，并默认被所有的子项目继承。如果项目中不写依赖项，则会从父项目继承（属性全部继承）声明在父项目dependencies里的依赖项。


 2)dependencyManagement里只是声明依赖，并不实现引入，因此子项目需要显示的声明需要的依赖。如果不在子项目中声明依赖，是不会从父项目中继承的；只有在子项目中写了该依赖项，并且没有指定具体版本，才会从父项目中继承该项，并且version和scope都读取自父pom;如果子项目中指定了版本号，那么会使用子项目中指定的jar版本。同时dependencyManagement让子项目引用依赖，而不用显示的列出版本号。Maven会沿着父子层次向上走，直到找到一个拥有dependencyManagement元素的项目，然后它就会使用在这个dependencyManagement元素中指定的版本号,实现所有子项目使用的依赖项为同一版本。


 3）dependencyManagement 中的 dependencies 并不影响项目的依赖项；而独立dependencies元素则影响项目的依赖项。只有当外层的dependencies元素中没有指明版本信息时，dependencyManagement 中的 dependencies 元素才起作用。一个是项目依赖，一个是maven项目多模块情况时作依赖管理控制的。

6.distributionManagement

环境配置<distributionManagement>负责管理构件的发布

<repository>给出Maven部署当前项目的构件到远程库时，关于远程库的配置。示例如下