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

Maven settings.xml详解

settings.xml

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

<?xml version="1.0" encoding="UTF-8"?>
<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">
	
  <localRepository>/path/to/local/repo</localRepository>
  
  <interactiveMode>true</interactiveMode>
  
  <offline>false</offline>
  
  <pluginGroups>
  </pluginGroups>
  
  <proxies>
  </proxies>

  <servers>
  </servers>

  <mirrors>
  </mirrors>

  <profiles>
  </profiles>

  <activeProfiles>
  </activeProfiles>
  
</settings>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

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 标签包裹其他内容标签。用户通常不需要修改该标签内容

<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">
<!--Xml name space 的缩写，标识了该文档使用 http://maven.apache.org/SETTINGS/1.0.0 的命名空间  -->
xmlns="http://maven.apache.org/SETTINGS/1.0.0"
<!--标识xsd文件的命名空间，使用标准的http://www.w3.org/2001/XMLSchema-instance  -->
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
<!--标识xsd(文档结构定义文件)的URI -->
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd"
<!--如对该部分内容感兴趣，可以访问 https://blog.csdn.net/lengxiao1993/article/details/77914155  -->
</settings>
1
2
3
4
5
6
7
8
9
10
11

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

<pluginGroups>
  <pluginGroup>org.apache.maven.plugins</pluginGroup>
  <pluginGroup>org.codehaus.mojo</pluginGroup>
</pluginGroups>
1
2
3
4

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

<!--注意，仅仅引入插件并不能完成自动生成工作，仍然需要引入相关的依赖包和配置文件 -->
<!--如果想要了解mybatis包括其衍生框架的代码生成工具，
可以查阅https://blog.csdn.net/weixin_43740223/article/details/108283753 -->
...
<build>
<plugin>
  <groupId>org.mybatis.generator</groupId>
  <artifactId>mybatis-generator-maven-plugin</artifactId>
  <version>1.4.0</version>
  <configuration>
    <configurationFile>${pom.basedir}/src/main/resources/maven-plugins-mybatis-generator-config.xml</configurationFile>
    <overwrite>true</overwrite>
  </configuration>
</plugin>
</build>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

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

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

<pluginGroups>
    <!-- pluginGroup
     | Specifies a further group identifier to use for plugin lookup.
    <pluginGroup>com.your.plugins</pluginGroup>
    -->
	<pluginGroup>org.mybatis.generator</pluginGroup>
  </pluginGroups>
1
2
3
4
5
6
7

注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

官方提供的配置示例

<proxies>
   <proxy>
      <id>example-proxy</id>
      <active>true</active>
      <protocol>http</protocol>
      <host>proxy.example.com</host>
      <port>8080</port>
      <username>proxyuser</username>
      <password>somepassword</password>
      <nonProxyHosts>www.google.com|*.example.com</nonProxyHosts>
    </proxy>
  </proxies>
1
2
3
4
5
6
7
8
9
10
11
12

7. servers

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

server

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

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

Maven 多仓库下的依赖搜索机制 转载自： https://blog.csdn.net/fengdayuan/article/details/93089136

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

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

————————————————
版权声明：本文为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默认的中央仓库配置。

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

<servers>
  <server>
    <id>central-mirror</id>
      <username>admin</username>
      <password>admin123</password>
  </server>
</servers>

<mirrors>
<!-- 
个人MAVEN镜像
这里mirrorOf 配置的 central 表示该镜像是MAVEN中央仓库的镜像
因为个人搭建的nexus MAVEN 仓库没有开启匿名访问， 所以需要添加上述的server以验证访问，否则将出现401 Unauthorized错误
-->
		<mirror> 
            <id>central-mirror</id>
            <url>http://172.20.3.21:9876/repository/pm-public/</url>
            <mirrorOf>central</mirrorOf>
		</mirror>
  </mirrors>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

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

1. 全局仓库的配置

settings.xml

<servers>
  <server>
    <id>my-repo</id>
      <username>admin</username>
      <password>admin123</password>
  </server>
</servers>

<!-- 
如果你需要给自己配置的仓库配置镜像,如下所示。当然自己配的仓库一般也不需要再配置镜像了。
<mirrors>
  <mirror>
    <id>my-repo-mirrors</id>
    <url>http://172.20.3.21:9876/repository/pm-public/</url>
     <mirrorOf>my-repo</mirrorOf>
  </mirror>
</mirrors>
-->

<profiles>
      <profile>
<!-- 
profile 不仅能配置仓库，插件仓库，还能配置properties等信息。
如下配置了一个全局仓库，是一个代理ali新的public仓库的代理仓库。
因为个人搭建的nexus MAVEN 仓库没有开启匿名访问， 所以需要添加上述的server以验证访问，否则将出现401 Unauthorized错误

-->
          <id>my-repo-profile</id>
          <repositories>
              <repository>
                  <id>my-repo</id>
                  <url>http://172.20.3.21:9876/repository/pm-alibaba-https/</url>
                  <releases>
                      <enabled>true</enabled>
                  </releases>
                  <snapshots>
                      <enabled>true</enabled>
                  </snapshots>
              </repository>
          </repositories>
      </profile>
 </profiles>
<!-- profiles中定义profile需要激活才能生效 -->
<activeProfiles>
    <activeProfile>my-repo-profile</activeProfile>
</activeProfiles>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

2. 项目仓库的配置

POM.xml 中配置仓库信息

<!--这里定义的是一个发布仓库 -->    

<distributionManagement>
        <!--其他用户可以从该地址获取到发布的内容 -->
        <downloadUrl>http://172.20.3.21:9876/repository/pm-release/</downloadUrl>
        <status>deployed</status>
        <repository>
            <uniqueVersion>false</uniqueVersion>
            <id>release-pub-repo</id>
            <url>http://172.20.3.21:9876/repository/pm-release/</url>
        </repository>
</distributionManagement>
1
2
3
4
5
6
7
8
9
10
11
12

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

<!-- 
因为个人搭建的nexus MAVEN 仓库没有开启匿名访问， 所以需要添加上述的server以验证访问，否则将出现401 Unauthorized错误.
注意：这里的ID与POM中发布仓库的ID保持一致
-->
<servers>
  <server>
    <id>release-pub-repo</id>
      <username>admin</username>
      <password>admin123</password>
  </server>
</servers>
1
2
3
4
5
6
7
8
9
10
11

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

9. profiles

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

profile的三种激活方式

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

<profiles>
 	<profile>
    <id>test</id>
    <!-- 具体的一些配置-->
  </profile>
 </profiles>

  <activeProfiles>
    <!--指定profile的id进行激活 -->
    <activeProfile>test</activeProfile>
  </activeProfiles>
1
2
3
4
5
6
7
8
9
10
11

2. 通过activation匹配条件激活

<profiles>
 	<profile>
    <id>test</id>
<!--
如下是官网提供的示例，我加以解释。官网文档在有些地方的释义仍然不够清晰，因此我通过搜索和测试增加了说明。
-->
    <activation>
      <!--是否默认激活-->
      <activeByDefault>false</activeByDefault>
      	<!--JDK版本，符合1.5及其子版本，例如1.5.0_06 也符合条件-->
        <jdk>1.5</jdk>
      	<!--操作系统条件 -->
        <os>
          <!--操作系统名称 通过java函数 system.getProperty("os.name")获取 -->
          <name>Windows XP</name>
          <!--操作系统类别 Unix | Windows | Mac 不区分大小写 -->
          <family>Windows</family>
          <!--计算机CPU架构 通过java函数 system.getProperty("os.arch")获取 -->
          <arch>x86</arch>
          <!--操作系统版本号 通过java函数 system.getProperty("os.version")获取 -->
          <version>5.1.2600</version>
        </os>
      	<!--Maven中定义的具体的某个属性值是否匹配, 官网中解释到：a value which can be dereferenced within the POM by ${name}
				也就是可以在POM中通过占位符${}引用到的值，那么JAVA系统变量的值(所有通过System.getProperty("propertyName")也可以都可以在此处被设置并判断，
				如果你在项目中有某些特殊的值需要借由MAVEN判断并以此激活某些profile，可以通过System.setProperties() 设置到环境变量中，也可以直接在POM中的<properties>标签中定义
				当然，在POM中直接定义有些情况下意味着你必须根据变化修改你的代码并重新编译。-->
        <property>
          <name>mavenVersion</name>
          <value>2.0.3</value>
        </property>
      	<!--根据文件是否存在判断激活 -->
        <file>
          <!--指定路径的文件是否存在 -->
          <exists>${basedir}/file2.properties</exists>
          <!--指定路径的文件是否不存在 -->
          <missing>${basedir}/file1.properties</missing>
        </file>
    </activation>
    <!--配置仓库或者全局属性等 -->
    <repositories>
      ...
    </repositories>
    <properties>
      ...
    </properties>
  </profile>
 </profiles>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

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

3. 通过命令行指令激活

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

Activation

略。

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

Properties

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

示例如下

<profiles>
    <profile>
      <id>test</id>
      ...
      <properties>
        <user.install>${user.home}/our-project</user.install>
      </properties>
      ...
    </profile>
  </profiles>
1
2
3
4
5
6
7
8
9
10

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

Repositories && PluginRepositories

仓库配置，上文中我们已经解释了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 ，通过表格比较一下几种策略的不同

10. activeProfiles

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

<activeProfiles>
    <activeProfile>test</ activeProfile>
 </activeProfiles>
1
2
3

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