如果你是有一定的开发经验，我相信你一定被项目 lib 下的 JAR 包折磨过，如果碰上兼容问题，更是逐个下载不同版本 JAR 包进行替换排查，相信是每个程序员都不想再经历一边的噩梦。
Maven 的出现则大大降低开发人员的准备工作，让开发人员更专心与业务，下面即介绍 Maven 基本使用。
Maven 是一个项目管理工具，可以对 Java 项目进行构建、依赖管理。
一、基础配置
1. 仓库配置
在 Maven 中引入了仓库的概念，开发人员将所编写的 JAR 按照相应格式推送到仓库中，当其他开发者需要引用这个 jar 包时在工程中引用相应依赖，则会先从中央仓库进行下载到本地仓库，此时项目将读取本地仓库的内容。
对于部分组织或机构通常会在此基础上额外搭建私人仓库，在引用依赖时会先从私人仓库进行读取，如果未找到再从中央仓库下载至私人仓库，最后再下载到本地仓库。
通过这种方式开发者则无需再手动管理繁杂的项目 JAR 包，从而实现更高的效率。
2. 基本信息
一个最基本的 Maven 项目通常应包含如下内容，当我们引用一个模块时，也是通过
groupId
、
artifactId
、
version
三项内容进行确定。
下面是一个基本定义示例：
<project ...>
<modelVersion>4.0.0modelVersion>
<groupId>xyz.ibudaigroupId>
<artifactId>maven-demoartifactId>
<version>1.0.0-SNAPSHOTversion>
<version>maven demoversion>
<description>This is maven demo.description>
project>
二、依赖管理
1. 依赖引入
通过
dependencies
标签我们即可导入所需要的工程依赖。
<dependencies>
<dependency>
<groupId>mysqlgroupId>
<artifactId>mysql-connector-javaartifactId>
<version>8.0.27version>
<scope>runtimescope>
dependency>
dependencies>
其中
scope
的可选值如下：
2. 间接依赖
当项目需要引用到其它依赖时，只需指定所依赖的工程的基本信息即可，剩下的一切都交给 Maven 处理。即便是所要依赖的工程依赖了其它工程，我们也只需引入项目所直接的依赖的工程。
如下图示例中
Dependency-A
引用了
Dependency-B
，而
Dependency-B
又依赖于
Dependency-C
，在传统项目中若在
Dependency-A
中引用
Dependency-B
则需要同时手动添加
Dependency-B
与
Dependency-C
所对应的 JAR 包，但在 Maven 中我们只需要引入
Dependency-B
即可， Mavne 会自动将子模块所依赖的包导入。
依赖顺序
在 maven 工程中遵循先定义先导入的原则，即当存在多个相同间接依赖，优先导入其父依赖定义在前的简洁依赖。
举个例子，如工程中引入
Dependency-A
与
Dependency-B
两个依赖，二者又分别引用了不同版本的
Dependency-C
，但对于 Maven 而言最终编译时同一个依赖即便是不同的版本也只会选择一份。
其计算规则如下：若
Dependency-A
定义在
Dependency-B
之前则最终将导入
Dependency-A
中的 C-1.0 版本。而在右侧图例中虽然
Dependency-A
引入优先级高于
Dependency-B
，但是 C-2.0 的间接依赖层级高于 C-1.0，因此将导入 C-2.0 版本。
3. 依赖排除
在引用多个模块时可能会发生版本兼容冲突问题，通过
excludes
标签即可实现依赖排除。
如下我们在工程中引入了
demo-a
依赖，但其又引用
dependency-b
依赖，如想要在当前工程中移除
dependency-b
依赖，此时即可通过
excludes
标签将
dependency-b
排除依赖。
<dependencies>
<dependency>
<groupId>xyz.ibudaigroupId>
<artifactId>demo-aartifactId>
<version
>1.0.0version>
<excludes>
<exclude>
<groupId>xyz.ibudaigroupId>
<artifactId>dependency-bartifactId>
<version>1.0.0version>
exclude>
excludes>
dependency>
dependencies>
除了手动通过
excludes
标签排除依赖，被引模块也可以在导入依赖时通过
optional
标签禁用依赖传递。
上述示例中若在
demo-a
工程中引入
dependency-b
依赖时添加
optional
标签，那么其它工程在引入
demo-a
依赖时将不会将
dependency-b
作为间接依赖导入。
<dependencies>
<dependency>
<groupId>xyz.ibudaigroupId>
<artifactId>demo-bartifactId>
<version>1.0.0version>
<optional>trueoptional>
dependency>
dependencies>
4. 变量配置
当项目中引入了大量依赖，为了方便管理通常将引入依赖的版本通过变量进行统一配置，从而实现更直观的依赖管理。
通过
properties
标签即可自定义变量配置，然后使用
${}
引用变量。
<properties>
<mysql.version>8.0.30mysql.version>
<junit.version>4.13.2junit.version>
properties>
<dependencies>
<dependency>
<groupId>mysqlgroupId>
<artifactId>mysql-connector-javaartifactId>
<version>${mysql.version}version>
dependency>
<dependency>
<groupId>junitgroupId>
<artifactId>junitartifactId>
<version>${junit.version}version>
dependency>
dependencies>
三、模块配置
1. 模块管理
当我们项目包含多个子项目时，通过
modules
标签即可实现模块管理。
<modules>
<module>module-1module>
<module>module-2module>
modules>
如下在
maven-demo
中又包含了
module-1
和
module-2
两个工程。
2. 模块继承
通过
parent
即可标记当前模块的父模块，且子模块将会继承父模块中的所有依赖配置。子模块若没有指定的
groupId
和
version
默认继承父模块中的配置。
其中
relativePath
用于指定父模块的 POM 文件目录，省略时默认值为
../pom.xml
即当前目录的上一级中，若仍未找到则会在本地仓库中寻找。
<parent>
<groupId>xyz.ibudaigroupId>
<artifactId>maven-demoartifactId>
<version>1.0-SNAPSHOTversion>
<relativePath>../pom.xmlrelativePath>
parent>
<artifactId>module-1artifactId>
四、统一管理
1. 依赖管理
当一共项目包含多个模块，且多个模块引用了相同依赖时显然重复引用是不太合适的，而通过
dependencyManagement
即可很好的解决依赖共用的问题。
将项目依赖统一定义在父模块的
dependencyManagement
标签中，子模块只需继承父模块并在
dependencies
引入所需的依赖，便可自动读取父模块
dependencyManagement
所指定的版本。
dependencyManagement
既不会在当前模块引入依赖，也不会给其子模块引入依赖，但其可以被继承的，只有在子模块下同样声明了该依赖，才会引入到模块中，子模块中只需在依赖中引入
groupId
与
artifactId
即可, 也可以指定版本则会进行覆盖。
2. 模块示例
接下来以下图中的模块层级关系进行举例：
maven-demo
在
maven-demo
的
dependencyManagement
定义
mysql
和
junit
两个依赖。
<dependencyManagement>
<dependencies>
<dependency>
<groupId>mysqlgroupId>
<artifactId>mysql-connector-javaartifactId>
<version>8.0.30version>
dependency>
<dependency>
<groupId>junitgroupId>
<artifactId>junitartifactId>
<version>4.13.2version>
dependency>
dependencies>
dependencyManagement>
module-1
在
module-1
中继承
maven-demo
工程，引入 mysql，无需指定版本，将会自动读取父模块中
dependencyManagement
中所指定的版本。当然你也可以选择指定版本，则将会进行覆盖，但并不建议这么操作，将提高项目维护难度。
module-1
的 pom 文件内容如下：
<parent>
<groupId>xyz.ibudaigroupId>
<artifactId>maven-demoartifactId>
<version>1.0-SNAPSHOTversion>
parent>
<dependencies>
<dependency>
<groupId>mysqlgroupId>
<artifactId>mysql-connector-javaartifactId>
dependency>
dependencies>
module-2
在
module-2
配置同
module-1
，通过
dependencyManagement
我们即实现了项目依赖版本的统一管理。
<parent>
<groupId>xyz.ibudaigroupId>
<artifactId>maven-demoartifactId>
<version>1.0-SNAPSHOTversion>
parent>
<dependencies>
<dependency>
<groupId>junitgroupId>
<artifactId>junitartifactId>
dependency>
dependencies>
3. 依赖导入
上面介绍了如何通过
dependencyManagement
实现全局的依赖版本管理，但如果工程中的两个子模块都需要配置相同的
dependencyManagement
配置时，当然你可以选择通过继承父模块来实现，也可以用笨办法直接复制粘贴一份。
在上述的
maven-demo
创建同级模块
maven-demo1
，如果要实现
maven-demo
中配置的
dependencyManagement
则在其
dependencyManagement
配置中导入
maven-demo
并将
scope
设置为
import
，并将
type
设置为
pom
。
通过导入即可实现更轻量化的模块信息继承，具体配置内容如下：
<dependencyManagement>
<dependencies>
<dependency>
<groupId>xyz.ibudaigroupId>
<artifactId>maven-demoartifactId>
<version>1.0.0-SNAPSHOTversion>
<scope>importscope>
<type>pomtype>
dependency>
dependencies>
dependencyManagement>
五、插件管理
经过前面的介绍相信对于 Maven 你已经有了一个初步的了解，但 Maven 除了依赖管理之外提供一系列强大的插件，插件对于 Maven 而言可谓时左膀右臂但却经常被人忽略。
今天就让我介绍一下 Maven 中常用的构建插件。
1. Jar
在使用 Java 开发时通常情况下我们都会将工程打包为 JAR 文件，首先了解一下 JAR 的文件结构。
下图即为通过 Maven 打包后的 JAR 文件，其中
org.example
目录为工程中定义的包名，存在编译后的
.class
文件，
META-INF
目录用于存放工程的元数据信息。
如上图中
META-INF
下的
MANIFEST.MF
文件内容如下：
Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Built-By: great
Created-By: Apache Maven 3.6.3
Build-Jdk: 1.8.0_202
而通过
maven-jar-plugin
插件我们即可在添加额外信息至打包后的 JAR 文件，插件配置信息如下：
<plugin>
<groupId>org.apache.maven.pluginsgroupId>
<artifactId>maven-jar-pluginartifactId>
<version>2.3.1version>
<configuration>
<archive>
<manifest>
<mainClass>org.example.MyTestmainClass>
<addDefaultSpecificationEntries>trueaddDefaultSpecificationEntries>
<addDefaultImplementationEntries>trueaddDefaultImplementationEntries>
manifest>
<manifestEntries>
<Plugin-Id>demo-pluginPlugin-Id>
<Plugin-Version>1.0.0Plugin-Version>
manifestEntries>
archive>
configuration>
plugin>
在之前的工程 POM 文件中添加上述构建插件重新进行打包，可以看到
MANIFEST.MF
文件中即添加了我们配置的额外属性。
Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Created-By: Apache Maven
Built-By: great
Build-Jdk: 1.8.0_202
# Specification entries
Specification-Title: maven-v1
Specification-Version: 1.0-SNAPSHOT
# Implementation entries
Implementation-Title: maven-v1
Implementation-Version: 1.0-SNAPSHOT
Implementation-Vendor-Id: org.example
# Manifest
Main-Class: org.example.MyTest
# ManifestEntries
Plugin-Id: demo-plugin
Plugin-Version: 1.0.0
2. Assembly
在普通 Maven 工程打包时默认仅会编译工程中新建的 java 文件并存储其
.class
文件，对于
POM
文件中引用的第三方依赖并不会一同打包。
如新建一个 Maven 工程并在依赖中导入
Jackson
依赖库并进行打包编译，可以看到下图编译后的 JAR 文件中只有工程中新建的
MyTest.class
文件，项目中所导入的依赖并没有被一起打包。
而通过
assembly
插件即可将 POM 配置中的所有依赖一同打包编译至 JAR 文件中。
其中
execution
标签定义了
assembly
插件的作用阶段，如这里设置了在
Maven package
即打包阶段生效。
<plugin>
<groupId>org.apache.maven.pluginsgroupId>
<artifactId>maven-assembly-pluginartifactId>
<version>3.1.0version>
<configuration>
<descriptorRefs>
<descriptorRef>jar-with-dependenciesdescriptorRef>
descriptorRefs>
<finalName>${project.artifactId}-${project.version}-allfinalName>
<appendAssemblyId>falseappendAssemblyId>
<attach>falseattach>
<archive>
<manifest>
<mainClass>fully.qualified.MainClassmainClass>
<addDefaultSpecificationEntries>trueaddDefaultSpecificationEntries>
<addDefaultImplementationEntries>trueaddDefaultImplementationEntries>
manifest>
archive>
configuration>
<executions>
<execution>
<id>make-assemblyid>
<phase>packagephase>
<goals>
<goal>singlegoal>
goals>
execution>
executions>
plugin>
在工程 POM 配置中添加上述信息并重新编译打包工程，可以看到此时 JAR 文件中除了自定义创建的
MyTest.clss
文件外同时包含了依赖的第三方库。
3. Shade
Shade 插件的功能更为强大，其提供了两个功能：第一个即与
assembly
类似可实现依赖的打包编译，与
assembly
不同的是 Shade 提供了更灵活的执行策略，可指定需要打包编译的依赖集合。
