Maven 最详细的settings.xml 配置文件解释

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

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

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

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

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

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

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

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

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

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

组成：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 ；即如下所示

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

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

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

注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 进行调用。不求甚解，望众位有则告知。

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

官方提供的配置示例

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

上文中我们提到四种仓库 依赖仓库， 插件仓库， 镜像仓库以及 发布仓库。实际上，这几种仓库本质上都是一种仓库， 无论插件，第三方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文件中的配置将生效

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

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

mirror

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

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

———————————————— 版权声明：本文为CSDN博主「wolf_fdy」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。 原文链接：https://blog.csdn.net/fengdayuan/article/details/93089136

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

settings.xml

POM.xml 中配置仓库信息

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

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

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

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

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

略。

参考 9. profile的三种激活方式 2.通过activation匹配条件激活

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

示例如下

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

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

首先，简单说明下maven的发布版本和快照版本。引用自：https://www.cnblogs.com/molao-doing/articles/6379216.html 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的版本管理原则。

然后针对 和 中的几个属性做下详细说明。 属性：enabled 键入： true | false 释义：是否启用发布 | 快照版本。

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

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

属性：checksumPolicy 键入：ignore | fail | warn 释义：比较工件校验和的策略。 首先需要理解校验和， 校验和是对传输位数的累加，用于校验maven构件的完整性和准确性。在传输时，发送方和接收方通过校验和检测本次数据传输是否传输完整，接受顺序是否有误(如果数据过大，传输可能是建立在多次链接之上的)。可以查阅 https://my.oschina.net/donhui/blog/325868 了解更多关于maven校验和的知识。 我们重新回到校验和的策略 checksumPolicy ，通过表格比较一下几种策略的不同

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

本文到此结束。感谢观看。