Maven配置文件详解
文章目录
Maven配置文件详解一、settings.xml配置文件的作用二、settings.xml元素详解0.示例1.LocalRepository2.InteractiveMode3.UsePluginRegistry4.Offline5.PluginGroups6.Servers7.Mirrors8.Proxies9.Profiles10.Activation11.properties12.Repositories13.pluginRepositories14.ActiveProfiles
三、maven查找依赖的顺序概述：①maven三类仓库说明②配置文件类型以及覆盖关系③依赖管理（不涉及模块的聚合和继承）：④pom模块的聚合和继承：⑤仓库依赖查找的顺序：
四、其他①定义在settings中的repositories和定义在profile中的repositories的区别② mirrors（镜像）和 repositories（仓库）是如何进行关联的③maven 在pom.xml和settings.xml的配置信息④dependencyManagement无法进行依赖导入问题
一、settings.xml配置文件的作用
①Maven目录下（全局配置）：${maven.home}/conf/setting.xml（可以用 mvn -v 命令查看安装的目录位置）
②用户目录下（用户级配置）：${user.home}/.m2/settings.xml（查 ~/.m2/settings.xml）
配置优先级从高到低：项目pom.xml > user settings > global settings
二、settings.xml元素详解
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"> jdbc:mysql://127.0.0.1:3306/test?useUnicode=true&characterEncoding=utf8
1.LocalRepository
构建系统本地仓库的路径。其默认值为~/.m2/repository
2.InteractiveMode
在 Maven 的配置文件（通常是 settings.xml 文件）中，
当
例如，当 Maven 构建一个项目时，如果设置了交互模式，它可能会提示用户选择特定的构建配置、确认下载依赖项、发布构件等。
然而，当
默认情况下，Maven 的
...
...
如果为false，命令如下 mvn archetype:generate -DgroupId=com.zworks -DartifactId=maven-setting -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false
需要指定groupId、artifactId、archetypeArtifactId，如果不指定会报错，因为这些是无法推测出值的。
如果为true，命令如下 mvn archetype:generate
后面会让你选择或输入archetype、groupId、artifactId、version、package、为false的时候之所以不用指定version和package是因为这两个都有默认值。
3.UsePluginRegistry
Maven是否需要使用plugin-registry.xml文件来管理插件版本。如果需要让Maven使用文件~/.m2/plugin-registry.xml来管理插件版本，则设为true。默认为false。
4.Offline
表示Maven是否需要在离线模式下运行。如果构建系统需要在离线模式下运行，则为true，默认为false。当由于网络设置原因或者安全因素，构建服务器不能连接远程仓库的时候，该配置就十分有用。
5.PluginGroups
当插件的组织Id（groupId）没有显式提供时，供搜寻插件组织Id（groupId）的列表。该元素包含一个pluginGroup元素列表，每个子元素包含了一个组织Id（groupId）。当我们使用某个插件，并且没有在命令行为其提供组织Id（groupId）的时候，Maven就会使用该列表。默认情况下该列表包含了org.apache.maven.plugins和org.codehaus.mojo
6.Servers
用来下载和部署的仓库是用POM中的repositories和distributionManagement元素来定义的。 但是某些配置例如username和password就不应该随着pom.xml来分配了。这种类型的信息应该保存在构建服务器中的settings.xml中。
7.Mirrors
为仓库列表配置的下载镜像列表
如果在
首先，Maven会按照
需要注意的是，不同的
8.Proxies
在这个例子中，配置了一个名为"myproxy"的代理服务器，使用HTTP协议连接到主机"proxy.somewhere.com"的8080端口。同时，提供了连接代理服务器时的认证信息（用户名和密码），以及不需要通过代理访问的主机名列表（*.google.com和ibiblio.org）。
9.Profiles
settings.xml中的profile是pom.xml中的profile的简洁形式。 它包含了激活(activation)，仓库(repositories)，插件仓库(pluginRepositories)和属性(properties)元素。 profile元素仅包含这四个元素是因为他们涉及到整个的构建系统，而不是个别的POM配置。 如果settings中的profile被激活，那么它的值将重载POM或者profiles.xml中的任何相等ID的profiles。
id：
作用：用于定义profile的唯一标识符，可以通过该id引用profile。 activation：
作用：用于指定何时激活profile，可以根据不同的条件来激活profile，例如环境变量、操作系统、Java版本等。activation标签可以包含如下子标签：
activeByDefault：指定是否默认激活profile。jdk：指定所需的JDK版本。os：指定操作系统条件。property：指定属性条件。file：指定文件是否存在条件。 properties：
作用：用于定义profile特定的属性，这些属性将覆盖全局属性或pom.xml中定义的属性。 dependencies：
作用：在profile中可以定义特定的依赖，这些依赖只会在激活了该profile的情况下被添加到项目中。 build：
作用：允许在profile中重新定义构建配置，包括插件、资源目录、输出目录等。 repositories：
作用：定义profile特定的仓库地址，这些仓库地址只会在激活了该profile的情况下被使用。 pluginRepositories：
作用：类似repositories标签，定义profile特定的插件仓库地址。 modules：
作用：定义profile特定的模块列表，这些模块只会在激活了该profile的情况下被构建。 distributionManagement：
作用：允许在profile中重新定义分发管理配置，包括部署仓库地址、站点生成配置等。
10.Activation
自动触发profile的条件逻辑。Activation是profile的开启钥匙。如POM中的profile一样，profile的力量来自于它能够在某些特定的环境中自动使用某些特定的值；这些环境通过activation元素指定。activation元素并不是激活profile的唯一方式。settings.xml文件中的activeProfile元素可以包含profile的id。profile也可以通过在命令行，使用-P标记和逗号分隔的列表来显式的激活（如，-P test）
11.properties
Maven的属性是值占位符，就像Ant中的属性。如果X是一个属性的话，那么它的值在POM中可以使用${X}来进行任意地方的访问。他们来自于五种不同的风格，所有都可以从settings.xml文件中访问到。
env.X：使用“env.”前缀将会返回当前的环境变量。例如
e
n
v
.
P
A
T
H
就是使用了
{env.PATH}就是使用了
env.PATH就是使用了path环境变量。 project.X：一个点“.”分割的路径，在POM中就是相关的元素的值。例如：1.0就可以通过
p
r
o
j
e
c
t
.
v
e
r
s
i
o
n
来访问。
s
e
t
t
i
n
g
s
.
X
：一个点“
.
”分割的路径，在
s
e
t
t
i
n
g
s
.
x
m
l
中就是相对应的元素的值，例如：
<
s
e
t
t
i
n
g
s
>
<
o
f
f
l
i
n
e
>
f
a
l
s
e
<
/
o
f
f
l
i
n
e
>
<
/
s
e
t
t
i
n
g
s
>
就可以通过
{project.version}来访问。 settings.X：一个点“.”分割的路径，在settings.xml中就是相对应的元素的值，例如：
project.version来访问。settings.X：一个点“.”分割的路径，在settings.xml中就是相对应的元素的值，例如：
j
a
v
a
.
h
o
m
e
X
：被
<
p
r
o
p
e
r
t
i
e
s
/
>
或者外部文件定义的属性，值可以这样访问
{java.home} X：被
java.homeX：被
jdbc:mysql://127.0.0.1:3306/test?useUnicode=true&characterEncoding=utf8
12.Repositories
远程仓库列表，它是Maven用来填充构建系统本地仓库所使用的一组远程项目
其中配置参数：
13.pluginRepositories
发现插件的远程仓库列表。仓库是两种主要构件的家。第一种构件被用作其它构件的依赖。这是中央仓库中存储的大部分构件类型。另外一种构件类型是插件。Maven插件是一种特殊类型的构件。由于这个原因，插件仓库独立于其它仓库。pluginRepositories元素的结构和repositories元素的结构类似。每个pluginRepository元素指定一个Maven可以用来寻找新插件的远程地址。
14.ActiveProfiles
手动激活profiles的列表，按照profile被应用的顺序定义activeProfile。 该元素包含了一组activeProfile元素，每个activeProfile都含有一个profile id。任何在activeProfile中定义的profile id，不论环境设置如何，其对应的 profile都会被激活。如果没有匹配的profile，则什么都不会发生。例如，env-test是一个activeProfile，则在pom.xml（或者profile.xml）中对应id的profile会被激活。如果运行过程中找不到这样一个profile，Maven则会像往常一样运行。
三、maven查找依赖的顺序概述：
①maven三类仓库说明
本地仓库（local）
本地仓库是 Maven 在本地机器上存储依赖项的地方。当你构建一个 Maven 项目时，Maven 会自动从中央仓库或其他远程仓库下载所需的依赖项，并将其存储在本地仓库中。这样，下次需要使用相同依赖时，Maven 就可以直接从本地仓库中获取而不必重新下载。
默认情况下，本地仓库位于用户主目录下的 .m2 目录中。你可以通过 settings.xml 文件中的
中央仓库（central）
中央仓库是 Maven 官方维护的一个仓库，包含了大量的开源 Java 项目的依赖项。当你在项目中声明了依赖项时，Maven 会自动从中央仓库下载所需的依赖项。
中央仓库中的所有内容都是公共可用的，因此任何人都可以访问其中的依赖项。如果你在使用 Maven 构建 Java 项目，那么中央仓库会是你最常用的仓库之一。
远程仓库（remote）
远程仓库是 Maven 中除了本地仓库和中央仓库之外的其他仓库。通常，一个企业或组织会自己搭建远程仓库来存储自己的私有依赖项或第三方依赖项，以便全公司或团队共享使用。
当你在项目中声明了依赖项时，如果中央仓库中没有对应的依赖项，Maven 就会尝试从所配置的远程仓库中下载该依赖项。你可以在 settings.xml 文件中的
②配置文件类型以及覆盖关系
配置文件类型：
项目级(Per Project):定义在项目POM.XML文件中用户级(Per User):定义在Maven的设置xml文件（${user.home}/.m2/settings.xml）全局(Global):定义在Maven全局的设置xml文件中（${maven.home}/conf/setting.xml）
覆盖关系说明：
上述配置文件类型优先级从上到下，即如果有相同的配置信息，项目级的配置覆盖用户级配置信息，用户级配置信息覆盖全局配置信息，Profile中的配置会覆盖Profile外的配置。
在 Maven 的多模块项目中，如果子模块POM中重写了父模块中的配置，子模块的配置会覆盖父模块的配置。
③依赖管理（不涉及模块的聚合和继承）：
**依赖：**项目所需的外部库、框架或其他项目的引用。这些依赖项会在构建过程中自动下载并添加到项目的类路径中，使得项目能够正常编译、运行和测试。示例：
**依赖属性：**POM 文件中的依赖通常以 XML 元素的形式列出，其中包括依赖项的坐标（groupId、artifactId、version）、Scope、Optional 等属性：
groupId：定义依赖项的组织或项目组的唯一标识符。通常以反向域名的形式命名，例如 com.example。 artifactId：定义依赖项的唯一标识符。它通常是项目或库的名称，例如 dependency1。 version：定义依赖项的版本号。Maven 使用版本号来确定要使用的依赖项版本。 scope：定义依赖项的可见性和生命周期。常用的 scope 有： 作用范围：
compile：默认的 scope，表示依赖项在编译、测试和运行时都需要使用。 test：表示依赖项仅在测试阶段使用，不会包含在最终构建的包中。 runtime：表示依赖项仅在运行时使用，而不是编译时。 provided：表示依赖项由 JDK 或容器提供，不需要在编译或运行时包含在项目中。 system：类似于 provided，但需要明确指定依赖项的路径。
Scope主程序范围测试程序范围是否打包范例Compile(默认)YYYLog4jTestYJunitProvidedYYServeet-apiRuntimeYJdbc依赖范围传递性： 带有依赖范围的资源在进行传递时，作用范围将受到影响，行：直接依赖，列：间接依赖 如package1中依赖了package2，package2中配置了依赖1，依赖1的scope是runtime，如果package1依赖package2的scope是test，那么其传递过来的依赖1的scope是test； 如package1中依赖了package2，package2中配置了依赖1，依赖1的scope是test，如果package1依赖package2的scope是test，那么package1就无法传递获得依赖1；
CompileTestProvidedRuntimeCompileCompileTestProvidedRuntimeTestProvidedRuntimeRuntimeTestProvidedRuntime optional：定义依赖项是否是可选的。可选依赖项不会强制要求用户将其包含在项目中。 exclusions：定义需要排除的传递性依赖项。可以指定一些依赖项，以防止它们被传递性地引入到项目中。 type：定义依赖项的类型。常见的类型有 JAR、WAR、POM 等。 classifier：对于同一 artifactId 和 version 的不同构建或版本，可以使用 classifier 进行区分。 具体示例，有一个项目需要同时使用 Log4j 1.x 和 Log4j 2.x 版本的库。这两个版本的 artifactId 和 groupId 都是相同的，所以无法通过这些属性来区分它们。但是，这两个版本的 JAR 包文件名有所不同，Log4j 1.x 版本的文件名为 log4j-1.2.17.jar，而 Log4j 2.x 版本的文件名为 log4j-api-2.14.1.jar。在这种情况下，可以使用 classifier 属性区分这两个版本，Log4j 1.x 版本的库被配置为 org.apache.logging.log4j:log4j:1.2.17:legacy，其中 legacy 是自定义的 classifier，用于区分 Log4j 1.x 版本。这样，项目就可以同时使用 Log4j 1.x 和 Log4j 2.x 版本的库，并且 Maven 会根据需要自动解析和下载相应版本的库。
重复依赖：
当在 Maven 的 pom.xml 文件中多次声明相同的依赖时，Maven 会根据以下规则处理这些重复的依赖
第一个声明的依赖会被保留，后续相同的依赖声明会被忽略。Maven 不会重复下载和处理已经存在的依赖项。如果多个相同依赖的声明具有不同的版本号，则 Maven 将使用声明中的最后一个版本。这意味着最后一次声明的版本将覆盖之前的版本。如果多个相同依赖的声明具有相同的版本号，那么 Maven 不会做任何特殊处理，它们都将被视为同一个依赖，并且只会下载一次。
使用相同的依赖声明多次可能是不必要的，并且会增加构建时间和项目大小。因此，建议在 pom.xml 文件中只声明一次所需的依赖，并确保版本号的一致性。如果需要引入不同版本的依赖，可以通过调整项目结构或使用 Maven 提供的解决依赖冲突的机制来解决
传递依赖：
依赖具有传递性：
直接依赖：在当前项目中通过依赖配置建立的依赖关系。间接依赖：被依赖的资源如果依赖其他资源，当前项目间接依赖其他资源。
依赖传递冲突问题：
由于依赖具有传递性，那么可能一个项目中可能存在多个相同的依赖，那么我们其使用依赖是哪一个呢？
路径优先（就近原则）：当依赖中出现相同的资源时，层级越深，优先级越低，层级越浅，优先级越高。声明优先：当资源在相同层级被依赖时，配置顺序靠前的覆盖配置顺序靠后的。特殊优先：当同级配置了相同资源的不同版本，后配置的覆盖先配置的。
可选依赖（不透明）:
可选依赖指对外隐藏当前所依赖的资源——不透明。
即在A加依赖B的时候，如果B的某个依赖的标签的值是true，那么B的该依赖对A隐藏。
排除依赖（不需要）：
排除依赖指主动断开依赖的资源，被排除的资源无需指定版本。
通过和来实现
④pom模块的聚合和继承：
聚合：
聚合的作用： 聚合用于快速构建maven工程，一次性构建多个项目/模块。
**多模块的构建维护：**在进行模块拆分后，如果某一个模块更新后，那么其他的模块都会因为该模块的原因而无法成功运行。那么我们这个时候就需要一个模块去统一管理这些模块，去负责这些模块的编译等功能（由该模块的功能执行，来对这些拆分的模块进行统一的功能执行），一个模块的活动对其他模块透明。
创建的方式：
创建一个空模块，打包类型定义为pom（一般是父模块）
定义当前模块进行构建操作时关联的其他模块名称
然后我们执行该继承模块的编译，可以发现其管理的模块依次执行编译操作,其顺序是根据依赖的顺序，从底到外进行依次执行的，如果并列的话，是根据配置的顺序进行执行的。 注意：参与聚合操作的模块最终执行顺序与模块间的依赖关系有关，与配置顺序无关
继承：
通过继承可以实现子工程中沿用父工程的配置
⑤仓库依赖查找的顺序：
https://www.jianshu.com/p/4ac4155b7cc3
https://blog.csdn.net/lishuoboy/article/details/119887006
maven项目中使用的仓库一共有有如下：
中央仓库 —— ① Maven 默认已经配置了中央仓库，你无需手动进行配置，默认的中央仓库URL为https://repo.maven.apache.org/maven2 如果需要使用自定义的中央仓库，可以在setting.xml文件中添加
将
Windows：C:\Users\{用户名}\.m2macOS/Linux：/Users/{用户名}/.m2
仓库分类：
本地仓库：⑦本地仓库
远程仓库：⑥项目profile仓库、⑤项目仓库、 ④全局profile仓库、③全局仓库、②镜像仓库【镜像仓库属于对中央仓库和其他远程仓库的镜像副本，本质上是远程仓库的一种形式，用于提供更高效的依赖下载】
中央仓库：①中央仓库
仓库依赖优先级：
即当重复配置仓库的时候，所生效的仓库，其顺序如下：
⑦本地仓库 -> ⑥项目profile仓库 -> ⑤项目仓库 -> ④全局profile仓库 -> ③全局仓库 -> ②镜像仓库 -> ①中央仓库
仓库查找依赖/插件顺序优先级：
本地仓库 -> 全局激活profile中的仓库 -> 用户激活profile中的仓库 -> 项目激活profile中的仓库 ->项目仓库 -> 用户级别设置的仓库 -> 全局仓库 -> 用户级别的镜像 -> 全局镜像
说明：
全局级别：Maven目录下，${maven.home}/conf/setting.xml
用户级别：用户目录下，${user.home}/.m2/settings.xml
项目界别：项目中的pom文件，pom.xml
这里特殊的是镜像仓库，镜像仓库在配置的时候通过mirrorOf标签匹配唯一的仓库id（如maven中央仓库id是central，在super pom中配置，当然还有各种各样自定义的仓库也有id），当远程仓库被镜像匹配到的，则在获取依赖的时候将从镜像仓库获取，而不是我们配置的repository仓库，此时repository仓库就是去作用。
四、其他
①定义在settings中的repositories和定义在profile中的repositories的区别
在Maven中，
全局配置文件中的
定义在全局配置文件中的
在项目的POM文件中，你可以定义多个
简而言之，全局配置文件中的
② mirrors（镜像）和 repositories（仓库）是如何进行关联的
在Maven中，
以下是镜像和仓库之间的关联方式：
在
在
关联的过程如下：
当Maven需要下载一个依赖或插件时，首先会检查
总之，
③maven 在pom.xml和settings.xml的配置信息
Maven 的 settings.xml 和项目的 pom.xml 是两个不同的配置文件，它们具有不同的作用和范围
settings.xml用于配置 Maven 的全局设置，如镜像仓库、代理服务器、全局属性等。这些全局配置对所有使用该 Maven 安装的项目都有效，并且在多个项目之间共享，相反，pom.xml 文件是项目特定的配置文件，位于项目根目录下，用于定义项目的依赖、构建配置和其他相关信息。pom.xml 文件中的配置是针对该特定项目的，并不会影响其他项目。
虽然有些全局配置可以在 pom.xml 中进行重定义，但并不是所有的全局配置都可以在 pom.xml 中进行替代。例如，settings.xml 中的代理服务器、镜像仓库等全局设置通常不能直接在 pom.xml 中进行配置。
④dependencyManagement无法进行依赖导入问题
通过dependency标签下载依赖，在假如到dependencyManagement中即可解决，原因是dependencyManagement无法自动下载声明的需要引入的依赖
参考文章
发表评论