Maven settings详解和配置仓库的几种方式和访问的顺序

目录

Maven settings.xml详解

settings.xml

conf 目录 和 .m2 目录

settings.xml加载规则

settings.xml 内容解析

1. settings

2. localRepository

3. interactiveMode

4. offline

5. pluginGroups

6. proxies

7. servers

8. mirrors

8. mirrorOf

9. profiles

10. activeProfiles

11.综上,我们配置仓库的话有以下几种方式

12.我想说的是

---

Maven settings.xml详解

settings.xml

maven的主配置文件缺省名称为 settings.xml 其完整结构如下(为了方便阅读，删除了注释部分)：

	
  /path/to/local/repo
  
  true
  
  false
  
  
  
  
  
  

  
  

  
  

  
  

  
  
  

conf 目录 和 .m2 目录

如果你是第一次安装maven，你能够在安装目录下的conf目录中找到settings.xml 配置文件，但如果你第一次使用maven进行项目构建后，你会发现在你的用户目录中，会出现一个.m2的隐藏(windows中非隐藏，. 前缀为linux内核操作系统中的隐藏文件前缀)目录。通常，我们会把 **conf目录 **中的settings.xml文件复制到 .m2目录中进行使用。实际上这是基于操作系统本身，相对于maven使用用户的一次分隔，不同的用户登录操作系统后将使用不同的settings.xml配置文件。如何达到这一目的，maven通过内置的settings.xml加载规则完成。

settings.xml加载规则

如上图所示，maven在构建项目获取配置文件时，首先会查找用户目录下的.m2目录，如果存在则使用，如果不存在再获取安装目录下conf目录中的配置文件，因此我们这样描述两个目录中配置文件的不同， .m2目录是用户级的配置，而conf目录是系统全局的配置。
**

注： 如果需要在项目构建时使用特定的配置文件，可以使用 **mvn -s 配置文件绝对路径 + 构建命令** 完成构建

settings.xml 内容解析

1. settings

settings.xml 除了默认的xml头之外，固定由一个 settings 标签包裹其他内容标签。用户通常不需要修改该标签内容

xmlns="http://maven.apache.org/SETTINGS/1.0.0"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd"

2. localRepository

输入内容：仓库目录的绝对路径
默认值： ${user.home}/.m2/repository
释义：配置maven 本地依赖仓库的绝对路径。也就是你通过pom.xml文件的dependencies定义的依赖，在maven构建(package 和 install 命令)时将被下载到这个本地仓库。

注：建议将仓库配置到系统运行盘以外的磁盘。

3. interactiveMode

输入内容：true | false
默认值： true
释义：Maven在运行时是否需要和用户交互以获得输入。如果Maven需要和用户交互以获得输入，则设置成true，反之则应为false。默认为true。

测试了一下，不知道这个交互体现在哪里，由于这个内容资料较少，且似乎没有太大的用处，因而这里不多讨论。

4. offline

输入内容：true | false
默认值： false
释义： 是否脱机运行，默认时false，也就是在构建项目时链接网络，如果设置为true，可能在下载依赖或者远程部署时会发生错误，建议保持默认值

5. pluginGroups

组成：pluginGroup
释义： 常用插件组的定义，包含多个 pluginGroup 标签。
maven除了提供内置的clean，test，package，install，deploy等插件之外， 还支持引入第三方插件。
在使用插件时，正式的命令是 mvn 插件groupId:插件artifactId:插件目的goal 例如 clean插件， mvn org.apache.maven.plugins:maven-clean-plugin:clean 。但如果你已经使用了一段时间maven，你会发生，更常使用的命令是mvn clean:clean 或者 mvn clean。为什么可以使用这些简写呢？正是由于pluginGroups和插件调用规则起的作用。
pluginGroups默认配置了 org.apache.maven.plugins和org.codehaus.mojo ；即如下所示

  org.apache.maven.plugins
  org.codehaus.mojo

一旦在pluginGroups中配置了插件的GroupId之后，也就意味着该插件组是你的常用插件(个人理解)，你就可以不书写groupId， 直接通过书写插件的昵称进行调用。
例如我在项目中引入mybatis-generator插件

...


  org.mybatis.generator
  mybatis-generator-maven-plugin
  1.4.0
  
    ${pom.basedir}/src/main/resources/maven-plugins-mybatis-generator-config.xml
    true
  

在未进行配置时， 我需要键入完整的插件索引才能执行插件，mvn org.mybatis.generator:mybatis-generator-maven-plugin:generate

而我们可以通过如下配置添加该插件组，此时我可以通过 mvn mybatis-generator:generate 直接进行插件的调用。

    
	org.mybatis.generator
  

注1：关于插件调用规则。有人注意到 mvn clean没有输入goal也能执行，那是因为当没有goal时，maven默认goal为 插件名 ，也就是你输入 mvn clean，实际上相当于 mvn clean:clean。例如有插件为 love 且其有goal设置为love， 我可以键入 mvn love:love，也可以直接键入 mvn love，
因此，当插件的名称与goal不同名时，请注意正确使用方法。
注2：pluginGroups 似乎仅在旧版本起作用，新版本测试时发现不需要配置也可以直接使用 mvn pluginName 进行调用。不求甚解，望众位有则告知。

6. proxies

组成：proxy
释义：配置网络代理服务器，以用于部分或全部HTTP请求。通常用不到，国内访问远程仓库可以配置仓库镜像，如果需要通过代理访问网络的话，可以用proxies配置代理。

proxy

属性	释义
id	代理的ID，默认default
active	是否激活该代理，默认true
protocol	代理服务器的协议，默认http
host	代理服务器的主机
port	代理服务器的端口，默认8080
username	代理服务器登录用户，仅在需要登录时配置
password	代理服务器登录密码，仅在需要登录时配置
nonProxyHosts	不使用该代理服务器的主机域名，多个域名使用

官方提供的配置示例

   
      example-proxy
      true
      http
      proxy.example.com
      8080
      proxyuser
      somepassword
      www.google.com|*.example.com
    
  

7. servers

组成：server
释义：用于配置 依赖下载存储库 (POM中的repositories | pluginRepositories中定义的存储库 && settings.xml 中 profile | mirror 中定义的存储库) 以及 发布工件的存储库(POM中的distributionManagement定义的发布仓库)的鉴权信息和权限设置。
因为有些设置不适合和项目工件一同进行发布，例如服务器链接和密码，这将可能导致密码泄露。 因而可以在配置发布和依赖下载的仓库后，如果访问仓库需要进行鉴权，可以在settings.xml 中的servers块中进行定义，两者通过id进行关联。

server

属性	释义
id	存储库的id，与POM中的repositories
username	访问存储库的用户名，当访问需要验证身份时，配置password填写验证信息
password	访问存储库的密码，当访问需要验证身份时，配置username填写验证信息
privateKey	访问存储库的ss密钥路径，如果访问需要遵守ssh安全协议且采用密钥认证的话。 默认在本地的 ${user.home}/.ssh/id_dsa 目录中
passphrase	访问存储库的ssh口令，如果访问需要遵守ssh安全协议且采用口令认证的话。
filePermissions	发布时创建的文件的访问权限，采用*nix文件权限格式，也就是我们常用的linux文件权限一样。例如775等
directoryPermissions	发布时创建的目录的访问权限，采用*nix文件权限格式，也就是我们常用的linux文件权限一样。例如775等
configuration	访问存储库的一些其他配置，只有在访问特定类型的存储库时才可能用到，本文不多讨论。详情参考官网http://maven.apache.org/guides/mini/guide-wagon-providers.html

上文中我们提到四种仓库 依赖仓库， 插件仓库， 镜像仓库以及 发布仓库。实际上，这几种仓库本质上都是一种仓库， 无论插件，第三方jar包还是项目构建的包文件都以几种特定的类型(jar | pom )存储在maven仓库中。

maven的仓库仅根据仓库的访问方式不同区分为 本地仓库 ， 远程仓库。

本地仓库通过本机系统的文件服务器访问，

远程仓库通过网络获取资源同步到本地仓库实现访问。

其中远程仓库又分为 maven中央仓库， 私服(镜像)仓库， 其他仓库，之所以存在这些类型，是因为中央仓库的服务器资源有限，因而产生私服(镜像)仓库，私服(镜像)仓库将同步中央仓库的maven工件，用户在使用私服下载maven工件时通常更加高效。其他的仓库可能存储了一些特定的maven工件， 例如企业内部搭建的maven发布仓库，该企业自主研发的maven工件将存储在这些仓库中。

之所以提到这些，是希望能了解 maven仓库的一些实质后，帮助我们更好的理解 server 标签的使用。我们现在就能够这样认为， 只要你在maven项目中使用POM 或者 settings 配置了存储库（不管是发布工件的仓库，还是镜像仓库，或者一般的存储库，或者是插件仓库），如果这些存储库的访问需要验证，就可以使用 settings.xml 中的 server标签进行认证信息的设置，通过id进行关联。

注：一些推论(验证教麻烦，后续补充)。
这里还会有一个ID重复的问题， 如果你在POM 和 settings中配置了同样ID的存储库，那么根据配置文件的优先级${PROJECT_HOME}/pom.xml > ${USER_HOME}/.m2/settings.xml > ${MAVEN_HOME}/conf/settings.xml 应该是POM文件中的配置将生效

8. mirrors

这一章部分内容与上一章 servers 相关，建议一起阅读
组成：mirror
释义：配置仓库的镜像地址，相当于仓库的拦截器。当用户需要下载依赖时，maven会首先搜索本地仓库，本地仓库找不到时则查找远程仓库，如果此时发现远程仓库有镜像，则转而从镜像仓库中下载相应的工件。

注：mirror的匹配规则：使用mirrorOf配置匹配仓库ID， 且MAVEN仅使用匹配到的第一个镜像，其余符合匹配条件的镜像将不起作用。也就是说，如果你的第一个仓库的mirrorOf 配置为 * ，则其余镜像配置将不起作用

mirror

属性	释义
id	该仓库镜像的唯一标识，与其他 mirror块 不重名即可，如果访问该镜像需要验证信息，可以在server中进行配置，通过id关联。 注：注意是配置的id，不是仓库本身的id
name	该仓库镜像的名称，与其他mirror块 不重名即可
url	仓库镜像的访问地址，仅支持 http 协议 和 https 协议
mirrorOf	被镜像的仓库的id，允许使用通配符。如果访问的仓库的ID匹配该标签配置的内容，将采用该镜像代为执行其工作。mirrorOf支持基于字符串的统配匹配规则，具体使用可以查看官网 Maven – Guide to Mirror Settings 。 通常使用id或者 * 号进行匹配即可。

仅靠上述的描述，似乎还不能够解决一些问题，如果有多个仓库配置， maven怎么确定现在要从哪个仓库中获取依赖呢？ 镜像是通过镜像ID匹配的，哪仓库的ID在哪里配置？ 一个新的maven项目没有配置过任何的仓库，为什么能够下载依赖？抱着这些问题，我们继续往下看。

Maven 多仓库下的依赖搜索机制 转载自： maven配置多仓库依赖的搜索顺序_wolf_fdy的博客-CSDN博客

maven多仓库查找依赖的顺序大致如下：

1. 在本地仓库中寻找，如果没有则进入下一步。
2. 在全局配置的私服仓库（settings.xml中配置的并有激活）中寻找，如果没有则进入下一步。
3. 在项目自身配置的私服仓库（pom.xml）中寻找，如果没有则进入下一步。
4. 在默认设置的中央仓库中(id:central, url:Central Repository:)寻找，如果没有则终止寻找。

————————————————
版权声明：本文为CSDN博主「wolf_fdy」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：maven配置多仓库依赖的搜索顺序_wolf_fdy的博客-CSDN博客

注：
1、如果在找寻的过程中，如果发现该仓库有镜像设置，则用镜像的地址代替，例如现在进行到要在respository A仓库中查找某个依赖，但A仓库配置了mirror，则会转到从A的mirror中查找该依赖，不会再从A中查找。
2、settings.xml中配置的profile（激活的）下的respository优先级高于项目中pom文件配置的respository。
3、如果仓库的id设置成“central”，则该仓库会覆盖maven默认的中央仓库配置。

配置仓库的镜像及镜像仓库的验证信息示例

  
    central-mirror
      admin
      admin123
  




		 
            central-mirror
            http://172.20.3.21:9876/repository/pm-public/
            central
		
  

配置仓库及其验证信息示例

POM.xml 中配置仓库信息

    


        
        http://172.20.3.21:9876/repository/pm-release/
        deployed
        
            false
            release-pub-repo
            http://172.20.3.21:9876/repository/pm-release/
        

settings.xml 中使用server配置仓库访问认证信息

  
    release-pub-repo
      admin
      admin123
  

上述列举的示例，希望能够加强对仓库repository、镜像mirror以及服务器认证信息server这些配置的记忆。

8. mirrorOf

mirrorOf的写法规则:

第一种:central

如下图,central里面直接写一个仓库的ID,这表示这个other-mirror镜像仓库代替了ID为central的仓库,原本依赖是从central仓库下载,现在改为从other-mirror镜像仓库下载.

3. other-mirror
4. Other Mirror Repository
5. https://other-mirror.repo.other-company.com/maven2
6. central

 注意:镜像的ID和name要保证和其他镜像不重复.

其它写法规则:

• *= 代替一切仓库
• external:*= 匹配除使用本地主机或基于文件的存储库之外的所有存储库。当您想要排除为集成测试定义的重定向存储库时，将使用此选项。
• repo,repo1= 存储库或存储库 1
• *,!repo1= 除存储库 1 之外的所有内容

9. profiles

组成：profile {

                      activation;

                      properties

                      repositories;

                      pluginRepositories;

                       }profile
释义：settings.xml 中的 profiles 是 pom.xml 中的 profiles的精简版本，相对于pom中的profiles是项目中的配置文件，它是全局的配置文件。profiles能够完成 仓库配置 和 全局属性定义。每个配置存在于一个 标签中，注意该 profile 需要进行激活才能启用

profile的三种激活方式

1.通过activeProfile指定profile 的 id激活

 	
    test
    
  
 

  
    
    test
  

2.通过activation匹配条件激活 

 	
    test

    
      
      false
      	
        1.5
      	
        
          
          Windows XP
          
          Windows
          
          x86
          
          5.1.2600
        
      	
        
          mavenVersion
          2.0.3
        
      	
        
          
          ${basedir}/file2.properties
          
          ${basedir}/file1.properties
        
    
    
    
      ...
    
    
      ...
    
  
 

如上，当profile中activation的条件全部满足时，该profile将被激活，仓库和属性的配置将生效。当然，如果你配置 true 后面的条件就不会被匹配，该配置将作为默认激活项激活。

3.通过命令行指令激活

mvn -P test 通过-P 并指定 profileid 即可在运行构建时激活指定id 的profile

Properties

同pom.xml中properties标签的使用方式一致，相较于pom.xml是项目全局的属性配置 ，${user.home}/.m2/settings.xml中的properties是用户全局的属性配置。当然如果你是在 ${MAVEN_HOME}/conf/settings.xml 中配置的话就是系统全局的。

示例如下

    
      test
      ...
      
        ${user.home}/our-project
      
      ...
    
  

如上示例，在maven中可以通过 ${user.install} 引用该属性定义。maven的全部属性定义都可以使用占位符进行引用

Repositories && PluginRepositories

`repositories`针对项目本身的依赖，通过repositories进行自定义配置。
`pluginRepositories`针对的是maven命令需要的插件依赖地址（比如clean、install都是maven的插件），
通过rpluginRepositories进行自定义配置。

如果只配置了repositories 则打包时候默认的插件依赖会从阿里云的仓库获取。
 

仓库配置，上文中我们已经解释了maven多仓库时的搜索机制，这里就是我们定义全局仓库的地方。仓库和插件仓库的配置是一样的， 这里使用表格简单介绍一下必要的属性配置

属性	释义
id	仓库id，注意与其他仓库区分
name	仓库名称，方便用户的识别
url	仓库访问路径
releases	snapshot
layout	仓库的布局类型 default

首先，简单说明下maven的发布版本和快照版本。引用自：MAVEN snapshot快照和release发布库的区别、作用 - moyun- - 博客园
maven的工件分为release 和 snapshot 两种版本类型，release为稳定的发行版本，snapshot为不稳定版本，通常我们开发中都使用snapshot作为版本号。定义一个组件/模块为快照版本，只需要在pom文件中在该模块的版本号后加上**-SNAPSHOT**即可(注意这里必须是大写)。release版本不允许修改，每次进行release版本修改，发布必须提升版本号。而snapshot一般是开发过程中的迭代版本，snapshot更新后，引用的项目可以不修改版本号自动下载构建。同样的，maven中的仓库也依此分为两种，snapshot快照仓库和release发布仓库。snapshot快照仓库用于保存开发过程中的不稳定版本，release正式仓库则是用来保存稳定的发行版本。

我们知道，maven的依赖管理是基于版本管理的，对于发布状态的artifact，如果版本号相同，即使我们内部的镜像服务器上的组件比本地新，maven也不会主动下载的。如果我们在开发阶段都是基于正式发布版本来做依赖管理，那么遇到这个问题，就需要升级组件的版本号，可这样就明显不 符合要求和实际情况了。但是，如果是基于快照版本，那么问题就自热而然的解决了，而maven已经为我们准备好了这一切。
maven2会根据模块的版本号(pom文件中的version)中是否带有-SNAPSHOT来判断是快照版本还是正式版本。如果是快照版本，那么在 mvn deploy时会自动发布到快照版本库中，而使用快照版本的模块，在不更改版本号的情况下，直接编译打包时，maven会自动从镜像服务器上下载最新的快照版本。如果是正式发布版本，那么在mvn deploy时会自动发布到正式版本库中，而使用正式版本的模块，在不更改版本号的情况下，编译打包时如果本地已经存在该版本的模块则不会主动去镜像服务 器上下载。

所以，我们在开发阶段，可以将公用库的版本设置为快照版本，而被依赖组件则引用快照版本进行开发，在公用库的快照版本更新后，我们也不需要修改pom文件提示版本号来下载新的版本，直接mvn执行相关编译、打包命令即可重新下载最新的快照库了，从而也方便了我们进行开发，也不冲突MAVEN的版本管理原则。

然后针对 其 中的几个属性做下详细说明。

比如下面这个Centra仓库配置

       
           
                Central
                Central
               
                    http://192.168.0.200:8082/nexus/content/groups/public/
               
               
                    true
               
               
                    true
                    never
               
                default
           
       
 

属性：enabled
键入： true | false
释义：是否启用发布 | 快照版本。

eleases的enabled为true表示开启Central仓库的发布版本下载支持
snapshots的enabled为false表示关闭Central仓库的快照版本下载支持
根据该配置，maven只会从Central仓库下载发布版本的的构件，而不会下载快照的构件

属性：updatePolicy
键入：always | daily | interval:X | never
释义：maven在构建时根据更新策略会比较本地仓库工件和远程仓库工件，如果发现远程仓库的工件有更新，将重新获取该工件。

键入值	释义
always	总是比较更新
daily	默认的更新策略，每天进行一次比较更新，取值为当地时间
interval:X	X为分钟的整数值，构建时发现已经间隔X分钟后进行比较更新
never	从不进行比较更新

注：官网说明该更新仅支持快照版本，发行版本仍然是按照版本号获取的，一旦获取后将不进行比较更新。但是releases中仍然有该部分配置，因而是否是文档错误笔者未进行验证

属性：checksumPolicy
键入：ignore | fail | warn
释义：比较工件校验和的策略。
首先需要理解校验和， 校验和是对传输位数的累加，用于校验maven构件的完整性和准确性。在传输时，发送方和接收方通过校验和检测本次数据传输是否传输完整，接受顺序是否有误(如果数据过大，传输可能是建立在多次链接之上的)。可以查阅 maven私服nexus之校验和（checksums） - donghui - OSCHINA - 中文开源技术交流社区 了解更多关于maven校验和的知识。
我们重新回到校验和的策略 checksumPolicy ，通过表格比较一下几种策略的不同

键入值	释义
ignore	忽略校验和
fail	当maven发现校验和不一致时，将导致构建失败，并抛出异常
warn	当maven发现校验和不一致时，将输出警告信息，但不会导致构建失败 (默认)

10. activeProfiles

组成：activeProfile
释义：用于激活profile，上文中已有描述。

    test
 

11.综上,我们配置仓库的话有以下几种方式

1)配置在settiing文件的下的本地仓库

2).配置在settiing文件的下的下的下的远程仓库

3)配置在settiing文件的下的下的镜像仓库.

4)配置在POM文件的下的下的远程仓库   (几乎不用这种方式)

上面4个查找顺序为:   

第一: 先找settiing本地仓库,

第二: 再找settiing远程仓库/镜像仓库(如果远程仓库被镜像仓库代替的话就不会去远程仓库找了),

第三: 再找pom远程仓库/镜像仓库(如果远程仓库被镜像仓库代替的话就不会去远程仓库找了),

第四: 最后找默认仓库(maven的官方仓库).

12.我想说的是

仓库配置的话都在setting文件配置就好,      不要在pom文件配置

其他版本jdk配置的话都在pom文件配置就好,     不要在setting文件配置