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

引言

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

不过风趣的是：许多伙伴对Maven，似乎很熟，但又如同不熟；在了解上，处于似懂非懂的“量子羁绊态”，为什么这么说呢？原因很简单，要说不熟吧，偏偏每天都有所触摸；要说熟吧，但是对许多高级功用又仅是一知半解。

正因如此，为了辅佐咱们从“量子羁绊态”中走出来，本文会从零开始，带着咱们玩转Maven技能。当然，其实写这篇文章更大的意图，是为后续写《闲谈分布式》专栏做预备，究竟后续会频繁用到Maven构建多工程项目。

PS：个人编写的《技能人求职攻略》小册已完结，其间从技能总结开始，到制定期望、技能突击、简历优化、面试预备、面试技巧、谈薪技巧、面试复盘、选Offer方法、新人入职、进阶提升、职业规划、技能办理、涨薪换岗、仲裁补偿、副业兼职……，为咱们打造了一套“从求职到换岗”的一条龙服务，一同也为诸位预备了七折优惠码：3DoleNaE，感兴趣的小伙伴能够点击：s./ds/USoa2R3/了解详情！

一、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包而言，最好只针对测验环境有用，而编译环境、运转环境中，因为用不到单元测验，所以有没有办法移除呢？这时能够经过<score>标签来操控收效规模：例如：

<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；
• ……

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、聚合工程的构建

前面提到过，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.5、聚合打包越过测验

当咱们要做项目发版时，就需求对整个聚合工程的每个工程打包（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: dev
server:
  port: 80
---
# 出产环境
spring:
  profiles: prod
server:
  port: 81
---
# 测验环境
spring:
  profiles: test
server:
  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……的开源项目，都采用这种命名方法。不过，假如你要问我：“你为啥用_不用-啊”？别问，问便是我控几不住我寄几啊……，更何况有句话说的好：知错不改，善莫大焉！

到这儿，关于Maven常用的功用现已讲完了，掌握这些常识后，玩转Maven的难度应该不大，不过Maven的功用远不仅如此，就光说pom.xml这个文件，能够装备的标签有几百个，本文仅讲到了几十个算了。假如你对其他不常用的标签感兴趣，我整了一份POM帮助文档，和Nexus装置包一同放到了网盘里，有需求能够重视微信大众号：竹子爱熊猫，回复POM收取。