电脑装配网

四十五图,一万五千字!一文让你走出迷雾玩转Maven!

 人阅读 | 作者pangding | 时间:2024-03-03 11:15

Maven应该是大家的老熟客了,身为Java程序员,几乎每天都会跟他打交道。

不过有趣的是:很多伙伴对Maven,似乎很熟,但又好像不熟;在理解上,处于似懂非懂的“量子纠缠态”,为什么这么说呢?原因很简单,要说不熟吧,偏偏每天都有所接触;要说熟吧,可是对许多高级功能又仅是一知半解。

一、Maven快速上手/回顾

声明:如果基础够扎实的小伙伴,可以跳到1.3阶段(快速刷一遍当复习也行)。

Maven是专门用于构建、管理Java项目的工具,它为我们提供了标准化的项目结构,如下:

├─ProjectName// 项目名称│ ├─src// 根目录│ │ ├─main// 主目录│ │ │ ├─java// Java源码目录│ │ │ ├─resources//配置文件目录│ │ │ └─webapp// Web文件目录│ │ ├─test// 测试目录│ │ │ ├─java// Java测试代码目录│ │ │ └─resources// 测试资源目录│ └─pom.xml// Maven项目核心配置文件

同时也提供了一套标准的构建流程:

从编译,到测试、打包、发布……,涵盖整个项目开发的全流程。

并且最重要的一点,它还提供了依赖(Jar包)管理功能,回想大家最初学JavaEE时,想要用到一个外部的工具包,必须先从网上找到对应的Jar文件,接着将其手动丢到项目的lib目录下,当项目需要依赖的外部包达到几十个、每个外部包还依赖其他包时,这个过程无疑很痛苦。

而这一切的一切,随着Maven的出现,从此不复存在。

1.1、Maven安装指南

使用Maven前,必须先安装它,这时可以先去到Maven官网下载自己所需的版本:

下载进行解压后(不过解压的目录最好别带中文,否则后续会碰到一些问题),接着需要配置一下,总共分为四步。

①在系统环境中,新建一个MAVEN_HOME或M2_HOME的环境变量,值写成解压路径。

②找到Path变量并编辑,在其中新增一行,配置一下bin目录:

%M2_HOME%\bin

其实安装许多软件,都要配置这一步,到底是为啥呢?因为任何软件的bin目录,通常会存放一些可执行的脚本/工具,如JDK的bin目录中,就存放着javac、javap、jstack……一系列工具。如果不在Path中配置bin,那想要使用这些工具,只能去到JDK安装目录下的bin目录,然后才能使用。

不过当大家在Path中配置了bin之后,这个配置就会对全局生效,任何位置执行javac这类指令,都可以从Path中,找到对应的bin目录位置,然后调用其中提供的工具。

③找到Maven解压目录下的conf/settings.xml,然后点击编辑,找到<localRepository>标签,将其挪动到注释区域外,然后配置本地仓库位置:

<localRepository>自己选择一个空的本地目录(最好别带中文)</localRepository>

④由于Apache的官方镜像位于国外,平时拉取依赖比较慢,所以还需配置Maven国内的镜像源,这时在settings.xml文件中,先搜索<mirrors>标签,接着在其中配置阿里云的镜像地址:

<mirror> <id>alimaven</id> <name>aliyun maven</name> <url>http://maven.aliyun.com/nexus/content/groups/public/</url> <mirrorOf>central</mirrorOf> </mirror>

到这里,整个Maven安装流程全部结束,最后也可以在终端工具,执行mvn -v命令检测一下。

1.2、Maven入门指南

安装好Maven后,接着可以通过IDEA工具来创建Maven项目,不过要记得配置一下本地Maven及仓库位置:

在这里配置,是对全局生效,后续创建的所有Maven项目,都会使用这组配置。

1.2.1、IDEA创建Maven项目

接着就可以创建Maven项目,这个过程特别简单,先选择New Project:

这里选创建Maven项目,接着指定一下JDK,还可以选择是否使用骨架,选好后直接Next下一步:

这里需要写一下GAV坐标,稍微解释一下三个选项的含义:

GroupID:组织ID,一般写公司的名称缩写;ArtifactID:当前Maven工程的项目名字;Version:当前Maven工程的版本。

接着点下一步,然后选择一下项目的存储位置,最后点击Finish创建即可:

这一步结束后,就得到了一个纯净版的Maven项目,然后可以基于Maven实现依赖管理。

1.2.2、Maven依赖管理

最简单的依赖管理,总共就只有三步,如下:

①在pom.xml中,先写一个<dependencies>标签;②在<dependencies>标签中,使用<dependency>标签来导入依赖;③在<dependency>标签中,通过GAV坐标来导入依赖。

如果你不知道一个依赖的GAV该怎么写,可以去仓库索引中搜索,现在写个坐标来感受一下:

<dependencies> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-web</artifactId> <version>5.1.8.RELEASE</version> </dependency></dependencies>

引入GAV坐标后,依赖不会立马生效,需要手动刷新一下项目:

可以借助IDEA自带的Maven项目工具来进行刷新;也可以安装Maven-Helper插件,在项目上右键,然后通过Run Maven里的指令刷新。至此,大家就掌握了Maven的基本使用。

PS:如果你本地仓库中有依赖,但忘了GAV坐标怎么写,通过IDEA工具,在pom.xml文件中按下alt+insert快捷键,接着点击Dependency,可以做到可视化快捷导入。

1.2.3、依赖范围管理

有时候,有些依赖我们并不希望一直有效,比如典型的JUnit测试包,对于这类jar包而言,最好只针对测试环境有效,而编译环境、运行环境中,因为用不到单元测试,所以有没有办法移除呢?这时可以通过<scope>标签来控制生效范围:例如:

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <version>2.1.8.RELEASE</version> <scope>test</scope></dependency>

该标签共有五种取值方式,每种取值对应着一种依赖范围,而不同的依赖范围,生效的环境(classpath)也并不同,如下表所示:

依赖范围

编译环境

测试环境

运行环境

compile

生效

生效

生效

provided

生效

生效

不生效

system

生效

生效

不生效

runtime

不生效

生效

生效

test

不生效

生效

不生效

项目引入的所有依赖,如果不显式指定依赖范围,默认是compile,意味着所有环境下都生效,而一般的依赖包也无需更改,只有某些特殊的依赖,才需要手动配置一下。如:

JUnit、spring-test这类包,只在测试环境使用,所以配成test;Tomcat内置servlet-api包,为了避免在运行环境冲突,应该配成provided;……

同时,<scope>标签还可以通过自定义的方式来添加其他的scope范围,例如Maven插件中使用的scope值:

<dependency> <groupId>some.group</groupId> <artifactId>some-artifact</artifactId> <version>1.0</version> <scope>plugin</scope></dependency>

这里的plugin就是自定义的scope,表示该依赖只在Maven插件中生效。

最后,<scope>标签还有一类特殊、但很常用的取值范围,即import,但这个放在后面去讲。

1.3、Maven工作原理剖析

在Maven中,节点会分为工程、仓库两大类,工程是“依赖使用者”,仓库是“依赖提供者”,关系如下:

看着或许有点头大,要讲明白得先弄清里面三种仓库:

中央仓库:就是前面配置的镜像源,里面拥有海量的公共jar包资源;远程仓库:也叫私服仓库,主要存储公司内部的jar包资源,这个后续会细说;本地仓库:自己电脑本地的仓库,会在磁盘上存储jar包资源。

大致了解三种仓库的含义后,接着来梳理Maven的工作流程:

①项目通过GAV坐标引入依赖,首先会去本地仓库查找jar包;②如果在本地仓库中找到了,直接把依赖载入到当前工程的External Libraries中;③如果没找到,则去读取settings.xml文件,判断是否存在私服配置;④如果有私服配置,根据配置的地址找到远程仓库,接着拉取依赖到本地仓库;⑤如果远程仓库中没有依赖,根据私服配置去中央仓库拉取,然后放到私服、本地仓库;⑥从远程或中央仓库中,把依赖下载到本地后,再重复第二步,把依赖载入到项目中。

上述六步便是Maven的完整工作流程,可能许多人没接触过私服,这个会放到后面聊。如果你的项目没配置Maven私服,那么第三步时,会直接从settings.xml读取镜像源配置,直接去到中央仓库拉取依赖。

不过这里有个问题,拉取/引入依赖时,Maven是怎么知道要找谁呢?答案是依靠GAV坐标,大家可以去观察一下本地仓库,当你引入一个依赖后,本地仓库中的目录,会跟你的GAV坐标一一对应,如:

无论是什么类型的仓库,都会遵循这个原则进行构建,所以,只要你书写了正确的GAV坐标,就一定能够找到所需的依赖,并将其载入到项目中。

1.4、Maven生命周期

通过IDEA工具的辅助,能很轻易看见Maven的九种Lifecycle命令,如下:

双击其中任何一个,都会执行相应的Maven构建动作,为啥IDEA能实现这个功能呢?道理很简单,因为IDEA封装了Maven提供的命令,如:点击图中的clean,本质是在当前目录中,执行了mvn clean命令,下面解释一下每个命令的作用:

clean:清除当前工程编译后生成的文件(即删除target整个目录);validate:对工程进行基础验证,如工程结构、pom、资源文件等是否正确;compile:对src/main/java目录下的源码进行编译(会生成target目录);test:编译并执行src/test/java/目录下的所有测试用例;package:将当前项目打包,普通项目打jar包,webapp项目打war包;verify:验证工程所有代码、配置进行是否正确,如类中代码的语法检测等;install:将当前工程打包,然后安装到本地仓库,别人可通过GAV导入;site:生成项目的概述、源码测试覆盖率、开发者列表等站点文档(需要额外配置);deploy:将当前工程对应的包,上传到远程仓库,提供给他人使用(私服会用)。

上述便是九个周期阶段命令的释义,而Maven总共划分了三套生命周期:

主要看default这套,该生命周期涵盖了构建过程中的检测、编译、测试、打包、验证、安装、部署每个阶段。注意一点:同一生命周期内,执行后面的命令,前面的所有命令会自动执行!比如现在执行一条命令:

mvn test

test命令位于default这个生命周期内,所以它会先执行validate、compile这两个阶段,然后才会真正执行test阶段。同时,还可以一起执行多个命令,如:

mvn clean install

这两个命令隶属于不同的周期,所以会这样执行:先执行clean周期里的pre-clean、clean,再执行default周期中,validate~install这个闭区间内的所有阶段。

从上面不难发现,default是Maven的核心周期,但其实上面并没有给完整,因为官方定义的default一共包含23个小阶段,上面的图只列出了七个核心周期,对详细阶段感兴趣的可以自行了解。

Maven中只定义了三套生命周期,以及每套周期会包含哪些阶段,而每个阶段具体执行的操作,这会交给插件去干,也就是说:Maven插件会实现生命周期中的每个阶段,这也是大家为什么看到IDEA的Lifecycle下面,还会有个Plugins的原因:

当你双击Lifecycle中的某个生命周期阶段,实际会调用Plugins中对应的插件。在Shell窗口执行mvn命令时,亦是如此,因为插件对应的实现包,都会以jar包形式存储在本地仓库里。

你有特殊的需求,也可以在pom.xml的<build>标签中,依靠<plugins>插件来导入。

二、Maven进阶操作

上面所说到的一些知识,仅仅只是Maven的基本操作,而它作为Java项目管理占有率最高的工具,还提供了一系列高阶功能,例如属性管理、多模块开发、聚合工程等,不过这里先来说说依赖冲突。

2.1、依赖冲突

依赖冲突是指:在Maven项目中,当多个依赖包,引入了同一份类库的不同版本时,可能会导致编译错误或运行时异常。这种情况下,想要解决依赖冲突,可以靠升级/降级某些依赖项的版本,从而让不同依赖引入的同一类库,保持一致的版本号。

另外,还可以通过隐藏依赖、或者排除特定的依赖项来解决问题。但是想搞明白这些,首先得理解Maven中的依赖传递性,一起来看看。

2.1.1、依赖的传递性

先来看个例子:

目前的工程中,仅导入了一个spring-web依赖,可是从下面的依赖树来看,web还间接依赖于beans、core包,而core包又依赖于jcl包,此时就出现了依赖传递,所谓的依赖传递是指:当引入的一个包,如果依赖于其他包(类库),当前的工程就必须再把其他包引入进来。

这相当于无限套娃,而这类“套娃”引入的包,被称为间接性依赖。与之对应的是直接性依赖,即:当前工程的pom.xml中,直接通过GAV坐标引入的包。既然如此,那么一个工程内的依赖包,就必然会出现层级,如:

在这里我们仅引入了一个boot-test坐标,但当打开依赖树时,会发现这一个包,依赖于其他许多包,而它所依赖的包又依赖于其他包……,如此不断套娃,最深套到了五层。而不同的包,根据自己所处的层级不同,会被划分为1、2、3、4……级。

2.1.2、自动解决冲突问题

Maven作为Apache旗下的产品,而且还经过这么多个版本迭代,对于依赖冲突问题,难道官方想不到吗?必然想到了,所以在绝对大多数情况下,依赖冲突问题并不需要我们考虑,Maven工具会自动解决,怎么解决的呢?就是基于前面所说的依赖层级,下面来详细说说。

①层级优先原则,Maven会根据依赖树的层级,来自动剔除相同的包,层级越浅,优先级越高。这是啥意思呢?同样来看个例子:

我们又通过GAV坐标导入了spring-web包,根据前面所说,web依赖于beans、core包,而beans包又依赖于core包,此时注意,这里出现了两个core包,前者的层级为2,后者的层级为3,所以Maven会自动将后者剔除,这点从图中也可明显看出,层级为3的core直接变灰了。

②声明优先原则,上条原则是基于层级深度,来自动剔除冲突的依赖,那假设同级出现两个相同的依赖怎么办?来看例子:

此时用GAV引入了web、jdbc两个包,来看右边的依赖树,web依赖于beans、core包,jdbc也依赖于这两个包,此时相同层级出现了依赖冲突,可从结果上来看,后面jdbc所依赖的两个包被剔除了,能明显看到一句:omitted for duplicate,这又是为啥呢?因为根据声明优先原则,同层级出现包冲突时,先声明的会覆盖后声明的,为此后者会被剔除。

③配置优先原则,此时问题又又来了,既然相同层级出现同版本的类库,前面的会覆盖后面的,可是当相同层级,出现不同版本的包呢?依旧来看例子:

此时pom引入了两个web包,前者版本为5.1.8,后者为5.1.2,这两个包的层级都是1,可是看右边的依赖树,此时会发现,5.1.8压根没引进来啊!为啥?这就是配置优先原则,同级出现不同版本的相同类库时,后配置的会覆盖先配置的。

所以大家发现了嘛?在很多时候,并不需要我们考虑依赖冲突问题,Maven会依据上述三条原则,帮我们智能化自动剔除冲突的依赖,其他包都会共享留下来的类库,只有当出现无法解决的冲突时,这才需要咱们手动介入。

通常来说,Maven如果无法自动解决冲突问题,会在构建过程中抛出异常并提供相关信息,这时大家可以根据给出的信息,手动排除指定依赖。

2.1.3、主动排除依赖

所谓的排除依赖,即是指从一个依赖包中,排除掉它依赖的其他包,如果出现了Maven无法自动解决的冲突,就可以基于这种手段进行处理,例如:

<dependency> <groupId>org.springframework</groupId> <artifactId>spring-web</artifactId> <version>5.1.8.RELEASE</version> <exclusions> <!-- 排除web包依赖的beans包 --> <exclusion> <groupId>org.springframework</groupId> <artifactId>spring-beans</artifactId> </exclusion> </exclusions></dependency>

从图中结果可以明显看出,通过这种方式,可以手动移除包所依赖的其他包。当出现冲突时,通过这种方式将冲突的两个包,移除掉其中一个即可。

其实还有种叫做“隐藏依赖”的手段,不过这种手段是用于多工程聚合项目,所以先讲清楚“多模块/工程”项目,接着再讲“隐藏依赖”。

2.2、Maven分模块开发

现如今,一个稍具规模的完整项目,通常都要考虑接入多端,如PC、WEB、APP端等,那此时问题来了,每个端之间的逻辑,多少会存在细微差异,如果将所有代码融入在一个Maven工程里,这无疑会显得十分臃肿!为了解决这个问题,Maven推出了分模块开发技术。

所谓的分模块开发,即是指创建多个Maven工程,组成一个完整项目。通常会先按某个维度划分出多个模块,接着为每个模块创建一个Maven工程,典型的拆分维度有三个:

①接入维度:按不同的接入端,将项目划分为多个模块,如APP、WEB、小程序等;②业务维度:根据业务性质,将项目划分为一个个业务模块,如前台、后台、用户等;③功能维度:共用代码做成基础模块,业务做成一个模块、API做成一个模块……。

当然,通常①、②会和③混合起来用,比如典型的“先根据代码功能拆分,再根据业务维度拆分”。

相较于把所有代码揉在一起的“大锅饭”,多模块开发的好处特别明显:

①简化项目管理,拆成多个模块/子系统后,每个模块可以独立编译、打包、发布等;②提高代码复用性,不同模块间可以相互引用,可以建立公共模块,减少代码冗余度;③方便团队协作,多人各司其职,负责不同的模块,Git管理时也能减少交叉冲突;④构建管理度更高,更方便做持续集成,可以根据需要灵活配置整个项目的构建流程;……

不过Maven2.0.9才开始支持聚合工程,在最初的时期里,想要实现分模块开发,需要手动先建立一个空的Java项目(Empty Project):

接着再在其中建立多个Maven Project:

然后再通过mvn install命令,将不同的Maven项目安装到本地仓库,其他工程才能通过GAV坐标引入。

这种传统方式特别吃力,尤其是多人开发时,另一个模块的代码更新了,必须手动去更新本地仓库的jar包;而且多个模块之间相互依赖时,构建起来额外的麻烦!正因如此,官方在后面推出了“聚合工程”,下面聊聊这个。

2.3、Maven聚合工程

所谓的聚合工程,即是指:一个项目允许创建多个子模块,多个子模块组成一个整体,可以统一进行项目的构建。不过想要弄明白聚合工程,得先清楚“父子工程”的概念:

父工程:不具备任何代码、仅有pom.xml的空项目,用来定义公共依赖、插件和配置;子工程:编写具体代码的子项目,可以继承父工程的配置、依赖项,还可以独立拓展。

而Maven聚合工程,就是基于父子工程结构,来将一个完整项目,划分出不同的层次,这种方式可以很好的管理多模块之间的依赖关系,以及构建顺序,大大提高了开发效率、维护性。并且当一个子工程更新时,聚合工程可以保障同步更新其他存在关联的子工程!

2.3.1、聚合工程入门指南

理解聚合工程是个什么东东之后,接着来聊聊如何创建聚合工程,首先要创建一个空的Maven项目,作为父工程,这时可以在IDEA创建Maven项目时,把打包方式选成POM,也可以创建一个普通的Maven项目,然后把src目录删掉,再修改一下pom.xml:

<!-- 写在当前项目GAV坐标下面 --><packaging>pom</packaging>

这样就得到了一个父工程,接着可以在此基础上,继续创建子工程:

当点击Next后,大家会发现:

这时无法手动指定G、V了,而是会从父工程中继承,最终效果如下:

这里我创建了两个子工程,所以父工程的pom.xml中,会用一个<modules>标签,来记录自己名下的子工程列表,而子工程的pom头,也多了一个<parent>标签包裹!大家看这个标签有没有眼熟感?大家可以去看一下SpringBoot项目,每个pom.xml文件的头,都是这样的。

这里提个问题:子工程下面能不能继续创建子工程?答案Yes,你可以无限套娃下去,不过我的建议是:一个聚合项目,最多只能有三层,路径太深反而会出现稀奇古怪的问题。

2.3.2、聚合工程的依赖管理

前面搭建好了聚合工程,接着来看个问题:

zhuzi_001、002两个子工程中,各自引入了三个依赖,可观察上图会发现,两者引入的依赖仅有一个不同,其余全部一模一样!所以这时,就出现了“依赖冗余”问题,那有没有好的方式解决呢?答案是有的,前面说过:公共的依赖、配置、插件等,都可以配置在父工程里,如下:

当把公共的依赖定义在父工程中,此时观察图中右侧的依赖树,会发现两个子工程都继承了父依赖。

不过此时问题又来了!为了防止不同子工程引入不同版本的依赖,最好的做法是在父工程中,统一对依赖的版本进行控制,规定所有子工程都使用同一版本的依赖,怎么做到这点呢?可以使用<dependencyManagement>标签来管理,例如:

在父工程中,<dependencies>里只定义了一个webmvc依赖,而<dependencyManagement>中定义了druid、test、jdbc三个依赖,这两个标签有何区别呢?

<dependencies>:定义强制性依赖,写在该标签里的依赖项,子工程必须强制继承;<dependencyManagement>:定义可选性依赖,该标签里的依赖项,子工程可选择使用。

相信这样解释后,大家对于两个标签的区别,就能一清二楚了!同时注意,子工程在使用<dependencyManagement>中已有的依赖项时,不需要写<version>版本号,版本号在父工程中统一管理,这就满足了前面的需求。这样做的好处在于:以后为项目的技术栈升级版本时,不需要单独修改每个子工程的POM,只需要修改父POM文件即可,大大提高了维护性!

2.3.3、聚合工程解决依赖冲突

之前传统的Maven项目会存在依赖冲突问题,那聚合工程中存不存在呢?当然存在,比如001中引入了jdbc、test这两个包,而002中也引入了,这时假设把001工程打包到本地仓库,在002工程中引入时,此时依赖是不是又冲突了?Yes,怎么处理呢?先看例子:

在上图中,001引入了aop包,接着通过install操作,把001工程打到了本地仓库。于是,在002工程中,引入了web、zhuzi_001这两个包。根据前面所说的依赖传递原则,002在引入001时,由于001引用了别的包,所以002被迫也引入了其他包。

还是那句话,大多数情况下,Maven会基于那三条原则,自动帮你剔除重复的依赖,如上图右边的依赖树所示,Maven自动剔除了重复依赖。这种结果显然是好现象,可是万一Maven不能自动剔除怎么办?这时就需要用到最开始所说的“隐藏依赖”技术了!

修改001的pom.xml,如下:

<dependency> <groupId>org.springframework</groupId> <artifactId>spring-aop</artifactId> <version>5.1.8.RELEASE</version> <optional>true</optional></dependency>

眼尖的小伙应该能发现,此时多了一个<optional>标签,该标签即是“隐藏依赖”的开关:

true:开启隐藏,当前依赖不会向其他工程传递,只保留给自己用;false:默认值,表示当前依赖会保持传递性,其他引入当前工程的项目会间接依赖。

此时重新把001打到本地仓库,再来看看依赖树关系:

当开启隐藏后,其他工程引入当前工程时,就不会再间接引入当前工程的隐藏依赖,因此来手动排除聚合工程中的依赖冲突问题。其他许多资料里,讲这块时,多少讲的有点令人迷糊,而相信看到这里,大家就一定理解了Maven依赖管理。

2.3.4、父工程的依赖传递

来思考一个问题,现在项目需要用到Spring-Cloud-Alibaba的多个依赖项,如Nacos、Sentinel……等,根据前面所说的原则,由于这些依赖项可能会在多个子工程用到,最好的方式是定义在父POM的<dependencyManagement>标签里,可是CloudAlibaba依赖这么多,一个个写未免太繁杂、冗余了吧?

面对上述问题时,该如何处理呢?如下:

<dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-alibaba-dependencies</artifactId> <version>${spring-cloud-alibaba.version}</version> <type>pom</type> <scope>import</scope></dependency>

<scope>标签取值为import的方式,通常会用在聚合工程的父工程中,不过必须配合<type>pom</type>使用,这是啥意思呢?这代表着:把spring-cloud-alibaba-dependencies的所有子依赖,作为当前项目的可选依赖向下传递。

而当前父工程下的所有子工程,在继承父POM时,也会将这些可选依赖继承过来,这时就可以直接选择使用某些依赖项啦,如:

<dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId></dependency><dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId></dependency>

2.3.5、聚合工程的构建

前面说到过,Maven聚合工程可以对所有子工程进行统一构建,这是啥意思呢?如果是传统的分模块项目,需要挨个进行打包、测试、安装……等工作,而聚合工程则不同,来看IDEA提供的Maven辅助工具:

尾巴上带有root标识的工程,意味着这是一个父工程,在我们的案例中,有一个父、两个子,来看IDEA的工具,除开给两个子工程提供了Lifecycle命令外,还给父工程提供了一套Lifecycle命令,这两者的区别在哪儿呢?当你双击父工程的某个Lifecycle命令,它找到父POM的<modules>标签,再根据其中的子工程列表,完成对整个聚合工程的构建工作。

大家可以去试一下,当你双击父工程Lifecycle下的clean,它会把你所有子工程的target目录删除。同理,执行其他命令时也一样,比如install命令,双击后它会把你所有的子工程,打包并安装到本地仓库,不过问题又又又来了!

假设这里001引用了002,002又引用了001,两者相互引用,Maven会如何构建啊?到底该先打包001,还是该先打包002?我没去看过Lifecycle插件的源码,不过相信背后的逻辑,应该跟Spring解决依赖循环类似,感兴趣的小伙伴可以自行去研究。不过我这里声明一点:Maven聚合工程的构建流程,跟<modules>标签里的书写顺序无关,它会自行去推断依赖关系,从而完成整个项目的构建。

2.3.6、聚合打包跳过测试

当大家要做项目发版时,就需要对整个聚合工程的每个工程打包(jar或war包),此时可以直接双击父工程里的package命令,但test命令在package之前,按照之前聊的生命周期原则,就会先执行test,再进行打包。

test阶段,会去找到所有子工程的src/test/java目录,并执行里面的测试用例,如果其中任何一个报错,就无法完成打包工作。而且就算不报错,执行所有测试用例也会特别耗时,这时该怎么办呢?可以选择跳过test阶段,在IDEA工具里的操作如下:

先选中test命令,接着点击上面的闪电图标,这时test就会画上横线,表示该阶段会跳过。如果你是在用mvn命令,那么打包跳过测试的命令如下:

mvn package –D skipTests

同时大家还可以在pom.xml里,配置插件来精准控制,比如跳过某个测试类不执行,配置规则如下:

<build> <plugins> <plugin> <artifactId>maven-surefire-plugin</artifactId> <version>2.22.1</version> <configuration> <skipTests>true</skipTests> <includes> <!-- 指定要执行的测试用例 --> <include>**/XXX*Test.java</include> </includes> <excludes> <!-- 执行要跳过的测试用例 --> <exclude>**/XXX*Test.java</exclude> </excludes> </configuration> </plugin> </plugins></build>

不过这个功能有点鸡肋,了解即可,通常不需要用到。

2.4、Maven属性

回到之前案例的父工程POM中,此时来思考一个问题:

虽然我们通过<dependencyManagement>标签,来控制了子工程中的依赖版本,可目前还有一个小问题:版本冗余!比如现在我想把Spring版本从5.1.8升级到5.2.0,虽然不需要去修改子工程的POM文件,可从上图中大家会发现,想升级Spring的版本,还需要修改多处地方!

咋办?总不能只升级其中一个依赖的版本吧?可如果全部都改一遍,无疑就太累了……,所以,这里我们可以通过Maven属性来做管理,我们可以在POM的<properties>标签中,自定义属性,如:

<properties> <spring.version>5.2.0.RELEASE</spring.version></properties>

而在POM的其他位置中,可以通过${}来引用该属性,例如:

这样做的好处特别明显,现在我想升级Spring版本,只需要修改一处地方即可!

除开可以自定义属性外,Maven也会有很多内置属性,大体可分为四类:

类型

使用方式

Maven内置属性

${属性名},如${version}

项目环境属性

${setting.属性名},如${settings.localRepository}

Java环境变量

${xxx.属性名},如${java.class.path}

系统环境变量

${env.属性名},如${env.USERNAME}

不过这些用的也不多,同时不需要记,要用的时候,IDEA工具会有提示:

2.5、Maven多环境配置

实际工作会分为开发、测试、生产等环境,不同环境的配置信息也略有不同,而大家都知道,我们可以通过spring.profiles.active属性,来动态使用不同环境的配置,而Maven为何又整出一个多环境配置出来呢?想要搞清楚,得先搭建一个SpringBoot版的Maven聚合工程。

首先创建一个只有POM的父工程,但要注意,这里是SpringBoot版聚合项目,需稍微改造:

<!-- 先把Spring Boot Starter声明为父工程 --><parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.1.5.RELEASE</version> <relativePath/></parent><!-- 当前父工程的GAV坐标 --><modelVersion>4.0.0</modelVersion><groupId>com.zhuzi</groupId><artifactId>maven_zhuzi</artifactId><version>1.0-SNAPSHOT</version><packaging>pom</packaging><!-- 配置JDK版本 --><properties> <java.version>8</java.version></properties><dependencies> <!-- 引入SpringBootWeb的Starter依赖 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency></dependencies><build><plugins> <!-- 引入SpringBoot整合Maven的插件 --> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> </plugin></plugins></build>

对比普通聚合工程的父POM来说,SpringBoot版的聚合工程,需要先把spring-boot-starter声明成自己的“爹”,同时需要引入SpringBoot相关的插件,并且我在这里还引入了一个boot-web依赖。

接着来创建子工程,在创建时记得选SpringBoot模板来创建,不过创建后记得改造POM:

<!-- 声明父工程 --><parent> <artifactId>maven_zhuzi</artifactId> <groupId>com.zhuzi</groupId> <version>1.0-SNAPSHOT</version></parent><modelVersion>4.0.0</modelVersion><!-- 子工程的描述信息 --><artifactId>boot_zhuzi_001</artifactId><name>boot_zhuzi_001</name><description>Demo project for Spring Boot</description>

就只需要这么多,因为SpringBoot的插件、依赖包,在父工程中已经声明了,这里会继承过来。

接着来做Maven多环境配置,找到父工程的POM进行修改,如下:

<profiles> <!-- 开发环境 --> <profile> <id>dev</id> <properties> <profile.active>dev</profile.active> </properties> </profile> <!-- 生产环境 --> <profile> <id>prod</id> <properties> <profile.active>prod</profile.active> </properties> <!-- activeByDefault=true,表示打包时,默认使用这个环境 --> <activation> <activeByDefault>true</activeByDefault> </activation> </profile> <!-- 测试环境 --> <profile> <id>test</id> <properties> <profile.active>test</profile.active> </properties> </profile></profiles>

配置完这个后,刷新当前Maven工程,IDEA中就会出现这个:

默认停留在prod上,这是因为POM中用<activeByDefault>标签指定了,接着去到子工程的application.yml中,完成Spring的多环境配置,如下:

# 设置启用的环境spring: profiles: active: ${profile.active}---# 开发环境spring: profiles: devserver: port: 80---# 生产环境spring: profiles: prodserver: port: 81---# 测试环境spring: profiles: testserver: port: 82---

这里可以通过文件来区分不同环境的配置信息,但我这里为了简单,就直接用---进行区分,这组配置大家应该很熟悉,也就是不同的环境中,使用不同的端口号,但唯一不同的是:以前spring.profiles.active属性会写上固定的值,而现在写的是${profile.active},这是为什么呢?

这代表从pom.xml中,读取profile.active属性值的意思,而父POM中配了三组值:dev、prod、test,所以当前子工程的POM,也会继承这组配置,而目前默认勾选在prod上,所以最终spring.profiles.active=prod,不过想要在application.yml读到pom.xml的值,还需在父POM中,加一个依赖和插件:

<!-- 开启 yml 文件的 ${} 取值支持 --><dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-configuration-processor</artifactId> <version>2.1.5.RELEASE</version> <optional>true</optional></dependency><!-- 添加插件,将项目的资源文件复制到输出目录中 --><plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-resources-plugin</artifactId> <version>3.2.0</version> <configuration> <encoding>UTF-8</encoding> <useDefaultDelimiters>true</useDefaultDelimiters> </configuration></plugin>

最后来尝试启动子工程,操作流程如下:

①在Maven工具的Profiles中勾选dev,并刷新当前项目;②接着找到子工程的启动类,并右键选择Run ……启动子项目。

先仔细看执行的结果,我来解释一下执行流程:

①启动时,pom.xml根据勾选的Profiles,使用相应的dev环境配置;②yml中${profile.active}会读到profile.active=dev,使用dev配置组;③application.yml中的dev配置组,server.port=80,所以最终通过80端口启动。

看完这个流程,大家明白最开始那个问题了吗?Maven为何还整了一个多环境配置?

大家可能有种似懂非懂的感觉,这里来说明一下,先把环境换到微服务项目中,假设有20个微服务,此时项目要上线或测试,所以需要更改配置信息,比如把数据库地址换成测试、线上地址等,而不同环境的配置,相信大家一定用application-dev.yml、application-prod.yml……做好了区分。

但就算提前准备了不同环境的配置,可到了切换环境时,还需要挨个服务修改spring.profiles.active这个值,从dev改成prod、test,然后才能使用对应的配置进行打包,可这里有20个微服务啊,难道要手动改20次吗?

而在父POM中配置了Maven多环境后,这时yml会读取pom.xml中的值,来使用不同的配置文件,此时大家就只需要在IDEA工具的Profiles中,把钩子从dev换到test、prod,然后刷新一下Maven,SpringBoot就能动态的切换配置文件,这是不是妙极了?因此,这才是Maven多环境的正确使用姿势!

三、Maven私服搭建

前面叨叨絮絮说了一大堆,最后就来聊聊Maven私服配置,为啥需要私服呢?

大家来设想这么个场景,假设你身在基建团队,主要负责研发各个业务开发组的公用组件,那么当你写完一个组件后,为了能让别的业务开发组用上,难道是先把代码打包,接着用U盘拷出来,给别人送过去嘛?有人说不至于,难道我不会直接发过去啊……

的确,用通讯软件发过去也行,但问题依旧在,假设你的组件升级了,又发一遍吗?所以,为了便于团队协作,搭建一个远程仓库很有必要,写完公用代码后,直接发布到远程仓库,别人需要用到时,直接从远程仓库拉取即可,而你升级组件后,只需要再发布一个新版本即可!

那远程仓库该怎么搭建呀?这就得用到Maven私服技术,最常用的就是基于Nexus来搭建。

3.1、Nexus私服搭建指南

Nexus是Sonatype公司开源的一款私服产品,大家可以先去到Nexus官网下载一下安装包,Nexus同样是一款解压即用的工具,不过也要注意:解压的目录中不能存在中文,否则后面启动不起来!

解压完成后,会看到两个目录:

nexus-x.x.x-xx:里面会放Nexus启动时所需要的依赖、环境配置;sonatype-work:存放Nexus运行时的工作数据,如存储上传的jar包等。

接着可以去到:

解压目录/etc/nexus-default.properties

这个文件修改默认配置,默认端口号是8081,如果你这个端口已被使用,就可以修改一下,否则通常不需要更改。接着可以去到解压目录的bin文件夹中,打开cmd终端,执行启动命令:

nexus.exe /run nexus

初次启动的过程会额外的慢,因为它需要初始化环境,创建工作空间、内嵌数据库等,直到看见这句提示:

此时才算启动成功,Nexus初次启动后,会在sonatype-work目录中生成一个/nexus3/admin.password文件,这里面存放着你的初始密码,默认账号就是admin,在浏览器输入:

http://localhost:8081

访问Nexus界面,接着可以在网页上通过初始密码登录,登录后就会让你修改密码,改完后就代表Nexus搭建成功(不过要记住,改完密码记得重新登录一次,否则后面的操作会没有权限)。

3.2、Nexus私服仓库

登录成功后,点击Browse会看到一些默认仓库,这里稍微解释一下每个字段的含义。

Name:仓库的名字;Type:仓库的类型;Format:仓库的格式;Status:仓库的状态;URL:仓库的网络地址。

重点来说说仓库的分类,总共有四种类型:

类型

释义

作用

hosted

宿主仓库

保存中央仓库中没有的资源,如自研组件

proxy

代理仓库

配置中央仓库,即镜像源,私服中没有时会去这个地址拉取

group

仓库组

用来对宿主、代理仓库分组,将多个仓库组合成一个对外服务

virtual

虚拟仓库

并非真实存在的仓库,类似于MySQL中的视图

仓库的关系如下:

本地的Maven需要配置私服地址,当项目需要的依赖,在本地仓库没有时,就会去到相应的宿主/远程仓库拉取;如果宿主仓库也没有,就会根据配置的代理仓库地址,去到中央仓库拉取,最后依次返回……。

3.3、Maven配置私服

Maven想要使用私服,需要先修改settings.xml文件,我的建议是别直接改,先拷贝一份出来,接着来讲讲配置步骤。

①修改settings.xml里的镜像源配置,之前配的阿里云镜像不能用了,改成:

<mirror> <id>nexus-zhuzi</id> <mirrorOf>*</mirrorOf> <url>http://localhost:8081/repository/maven-public/</url></mirror>

②在私服中修改访问权限,允许匿名用户访问,如下:

③在Nexus私服中配置一下代理仓库地址,即配置镜像源:

将这个默认的中央仓库地址,改为国内的阿里云镜像:

http://maven.aliyun.com/nexus/content/groups/public/

改完后记得拖动到最下方,点击Save保存一下即可。

④在Maven的settings.xml中,配置私服的账号密码:

<server> <id>zhuzi-release</id> <username>admin</username> <password>你的私服账号密码</password></server><server> <id>zhuzi-snapshot</id> <username>admin</username> <password>你的私服账号密码</password></server>

这两组配置,放到<servers>标签中的任何一处即可,这里可以先这样配置,看不懂没关系。

3.4、项目配置私服

前面配置好了本地Maven与私服的映射关系,接着要配置项目和私服的连接,说下流程。

①为项目创建对应的私服仓库,如果已有仓库,可以直接复用,创建步骤如下:

其中唯一值得一提的就是仓库格式,这里有三个可选项:

Release:稳定版,表示存放可以稳定使用的版本仓库;Snapshot:快照版,代表存储开发阶段的版本仓库;Mixed:混合版,不区分格式,表示混合存储代码的仓库。

为了规范性,我的建议是Release、Snapshot格式的仓库,各自都创建一个。

②在Maven工程的pom.xml文件中,配置对应的私服仓库地址,如下:

<!-- 配置当前工程,在私服中保存的具体位置 --><distributionManagement> <repository> <!-- 这里对应之前 settings.xml 里配置的server-id --> <id>zhuzi-release</id> <!-- 这里代表私服仓库的地址,大家只需要把后面的名字换掉即可 --> <url>http://localhost:8081/repository/zhuzi-release/</url> </repository> <snapshotRepository> <id>zhuzi-snapshot</id> <url>http://localhost:8081/repository/zhuzi-snapshot/</url> </snapshotRepository></distributionManagement>

③将当前项目发布到私服仓库,这里可以执行mvn clean deploy命令,也可以通过IDEA工具完成:

不过这里有一个细节要注意,由于配置了私服上的两个宿主仓库,一个为稳定仓库,另一个为快照仓库,所以发布时,默认会根据当前项目的<version>版本结尾,来选择上传到相应的仓库,例如上图中的结尾是SNAPSHOT,所以会被发布到快照仓库,如果结尾不是这个后缀时,就会被发布到Release仓库。

当发布完成后,大家就可以登录Nexus界面,找到对应的宿主仓库,查看相应的jar包信息啦!不过还有一点要注意:你要发布的包不能带有上级,即不能有parent依赖,否则在其他人在拉取该项目时,会找不到其父项目而构建失败。要解决这个问题,可以先将parent项目打包并上传至远程仓库,然后再发布依赖于该parent项目的子模块。

3.5、Nexus配置仓库组

前面在说仓库类型时,还提到过一个“仓库组”的概念,如果你目前所处的公司,是一个大型企业,不同团队都有着各自的宿主仓库,而你恰恰又需要用到其他团队的组件,这时难道需要在pom.xml中,将远程仓库地址先改为其他团队的地址吗?答案是不需要的,这时可以创建一个仓库组。

大家可以看到,图中的Members区域代表当前仓库组的成员,而这些成员会按照你排列的顺序,具备不同的优先级,越靠前的优先级越高。创建好仓库组后,接着可以去配置一下仓库组,这里有两种方式。

3.5.1、配置单个工程与仓库组的映射

这种方式只需修改pom.xml即可:

<repositories> <repository> <id>zhuzi-group</id> <!-- 配置仓库组的地址 --> <url>http://localhost:8081/repository/zhuzi-group/</url> <!-- 允许从中拉取稳定版的依赖 --> <releases> <enabled>true</enabled> </releases> <!-- 也允许从中拉取快照版的依赖 --> <snapshots> <enabled>true</enabled> </snapshots> </repository></repositories><pluginRepositories> <pluginRepository> <id>plugin-group</id> <url>http://localhost:8081/repository/zhuzi-group/</url> <releases> <enabled>true</enabled> </releases> <snapshots> <enabled>true</enabled> </snapshots> </pluginRepository></pluginRepositories>

在上述这组配置中,配置了<repositories>、<pluginRepositories>两个标签,分别是啥意思呢?很简单,第一个是普通依赖的仓库组地址,第二个是插件依赖的仓库组地址,前者针对于pom.xml中的<dependency>标签生效,后者针对<plugin>标签生效。

当你通过GAV坐标,引入一个依赖时,如果本地仓库中没找到,则会根据配置的仓库组地址,去到Nexus私服上拉取依赖。不过因为仓库组是由多个仓库组成的,所以拉取时,会根据仓库的优先级,依次搜索相应的依赖,第一个仓库将是最优先搜索的仓库。

3.5.2、配置本地Maven与仓库组的映射

上一种配置方式,只针对于单个Maven工程生效,如果你所有的Maven工程,都需要与Nexus私服上的仓库组绑定,这时就可以直接修改settings.xml文件,如下:

<profile><id>zhuzi-group</id><repositories><repository><id>nexus-maven</id><url>http://localhost:8081/repository/zhuzi-group/</url><releases><enabled>true</enabled><updatePolicy>always</updatePolicy></releases><snapshots><enabled>true</enabled><updatePolicy>always</updatePolicy></snapshots></repository></repositories> <pluginRepositories><pluginRepository><id>nexus-maven</id><url>http://localhost:8081/repository/zhuzi-group/</url><releases><enabled>true</enabled><updatePolicy>always</updatePolicy></releases><snapshots><enabled>true</enabled><updatePolicy>always</updatePolicy></snapshots></pluginRepository></pluginRepositories></profile>

这组配置要写在<profiles>标签里面,其他的与前一种方式没太大区别,唯一不同的是多了一个<updatePolicy>标签,该标签的作用是指定仓库镜像的更新策略,可选项如下:

always:每次需要Maven依赖时,都先尝试从远程仓库下载最新的依赖项;daily:每天首次使用某个依赖时,从远程仓库中下载一次依赖项;interval:X:每隔X个小时,下载一次远程仓库的依赖,X只能是整数;never:仅使用本地仓库中已经存在的依赖项,不尝试从远程仓库中拉取。

Maven工程使用依赖时,首先会从本地仓库中查找所需的依赖项,如果本地仓库没有,则从配置的远程仓库下载这时会根据<updatePolicy>策略来决定是否需要从远程仓库下载依赖。

不过上述这样配置后,还无法让配置生效,如果想要生效,还得激活一下上述配置:

<activeProfiles> <!-- 这里写前面配置的ID --><activeProfile>zhuzi-group</activeProfile></activeProfiles>

不过要记住,无论两种方式内的哪一种,都只允许从私服上拉取依赖,如果你的某个工程,想要打包发布到私服上,还是需要配置3.4阶段的<distributionManagement>标签。

四、Maven总结

最后,对于Maven项目的命名,不同单词最好用-减号分割,而不是_下划线,毕竟Spring、Apache……的开源项目,都采用这种命名方式。不过,如果你要问我:“你为啥用_不用-啊”?别问,问就是我控几不住我寄几啊……,更何况有句话说的好:知错不改,善莫大焉!

原文链接:https://juejin.cn/post/7238823745828405308


文章标签:

本文链接:『转载请注明出处』