maven工具

maven概括

• Maven 是一个项目管理和综合工具。Maven 提供了开发人员构建一个完整的生命周期框架。开发团队可以自动完成项目的基础工具建设，Maven 使用标准的目录结构和默认构建生命周期。
• 在多个开发团队环境时，Maven 可以设置按标准在非常短的时间里完成配置工作。由于大部分项目的设置都很简单，并且可重复使用，Maven 让开发人员的工作更轻松，同时创建报表，检查，构建和测试自动化设置。
• 概括地说，Maven 简化和标准化项目建设过程。处理编译，分配，文档，团队协作和其他任务的无缝连接。 Maven 增加可重用性并负责建立相关的任务。有了maven你的工作就简单了。

​idea自带一套maven的环境.使用idea开发,无需安装windows的maven。但是有的开发者,喜欢单独使用maven,windows单独安装了一套。

多模块开发 

pom.xml文件

每一个maven项目都有一个pom文件。Project Object Model 项目对象模型,maven作为一个项目开发管理工具,将每一个项目看成是一个对象.pom文件是描述这个对象的数据文件(元数据).通过pom文件的内容,maven软件就可以管理控制项目。maven管理工具是通过pom文件的元数据进行管理每一个项目对象，而pom文件是对项目对象的一个描述。

生命周期 

maven管理项目时,总是先加载pom然后执行声明周期的命令逻辑,maven项目从创建开始,要经历如下几个生命周期环节。

概念: 生命周期,对象目标经历的环节,经历的步骤。

底层执行命令：mvn validate/compile/test/package/install/site/deploy

validate：底层执行的maven命令，实际上是校验一下当前maven结构，环境是否符合maven项目开发要求。

compile：maven项目的编译，只负责main中相关内容的编译输出，默认输出到 target/classes。

test：执行项目的单元测试，会生成单元测试报告，包含前一步的compile，并且将测试代码编译输出。

package：将项目打包。根据packaging类型不一样,打包的输出结果就不同.类型有三种常用的jar/war/pom。第三种类型没有代码,只能作为父工程或者聚合工程使用。

install：将项目打包,安装存放到本地库(远程库,本地库.目前的远程库 central中央库)。

site：根据Maven配置生成一个html页面集.针对这个项目做的可观测页面。

deploy：和私服有关.公司开发,传递jar包的方式。

idea自定义运行命令：

执行自定义maven命令，添加一个选项-X可以在控制台打印maven执行命令的详细日志。目的是在出错的时候，帮助我们提供更准确的定位信息。

提问: 所有maven项目的生命周期经历的环节都完全一样么?

不一样，例如: ​ 项目运行的web应用: compile test package 项目是提供给同事复用的代码: compile test pakcage install deploy。

多模块特性 

依赖特性 

多模块管理依赖关系,意义在于可以实现代码复用.依赖特点具备传递性,但是可以通过去除实现精简的依赖。被依赖的资源本身也是maven项目，此资源也有可能需要依赖别人，这就很好的体现了以来的传递性。

<dependencies>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-context</artifactId>
        <version>5.2.22.RELEASE</version>
        <!--去除当前依赖,默认传递过来的其他依赖资源-->
        <exclusions>
            <exclusion>
                <groupId>org.springframework</groupId>
                <artifactId>spring-aop</artifactId>
            </exclusion>
            <exclusion>
                <groupId>org.springframework</groupId>
                <artifactId>spring-core</artifactId>
            </exclusion>
        </exclusions>
    </dependency>
</dependencies>

继承特性 

在同一个项目中不同模块的开发者中，各自维护自己的项目依赖关系，有可能出现图中的情况,相互关联的两个模块同时依赖A.jar，但是版本不同，会导致严重的结果,，相互之间的关系存在兼容问题，为了保证没有兼容问题。

继承意义：为了统一多模块协作多人开发版本资源,maven提供了一个多模块特性--继承

继承实现：确定父子关系(文件夹结构就是父子关系)。父工程packaging标签值必须是pom,子工程使用parent标签指向父工程(idea自动帮你实现了)。

parent标签详解：

<parent>
    <groupId>org.springframework.boot</groupId><!-- 一般公司域名 -->
    <artifactId>spring-boot-starter-parent</artifactId><!-- 一般工程名 -->
    <version>2.7.13</version><!-- 版本号 -->
    <relativePath/> <!-- lookup parent from repository -->
</parent>

relativePath: 子工程寻找父工程pom文件的相对路径地址。如果子工程无法找到父工程的pom,无法实现继承.这个值有三种配置方式。

• 默认值(不给标签) ../pom.xml
• 自定义值,根据你的pom位置,合理的编写路径信息(跨文件夹级别继承)
• 空值 只在本地库找父工程的pom文件,如果本地库没有,从远程库下载

本地库资源路径(必须掌握通过maven标签找到库资源)

• 本地库目录+<groupId>值+<artifactId>值+<version>
• 找本地库在哪c:/{User}/.m2/repository/org/springframework/boot/spring-boot-starter-parent/2.7.13

继承本质：子工程继承父工程, pom文件的继承,继承之后,获取的内容就是pom文件中的标签。pom文件中标签的复用 依赖才是代码的复用。 

常见的继承标签： groupId、version、properties、dependencies、dependencyManagement

dependencyManagement标签

依赖管理，在依赖管理标签定义的是依赖版本，dependencyManagement包含了一套完整的dependencies。

一旦在项目中定义了依赖管理，再使用依赖的时候,就可以省略版本号了。所以我们在父工程统一规划好所有的依赖资源版本，dependencyManagement被子工程继承之后，拥有了相同的特性，相当于做到了资源版本的统一定义，子工程尽可能不重写版本。

    <properties>
        <maven.compiler.source>8</maven.compiler.source>
        <maven.compiler.target>8</maven.compiler.target>
        <!--map key value spring.version=5.1.13.RELEASE-->
        <!--自定义当前开发项目版本号-->
        <spring.version>5.2.22.RELEASE</spring.version>
    </properties>
    <!--依赖管理-->
    <dependencyManagement>
        <!--在依赖管理中,交给当前工程maven所管理的依赖 1个-->
        <dependencies>
            <dependency>
                <groupId>org.springframework</groupId>
                <artifactId>spring-beans</artifactId>
                <version>${spring.version}</version>
            </dependency>
        </dependencies>
    </dependencyManagement>

问题：父工程定义一堆dependencies 也能实现统一管理资源版本，但是不建议使用，因为这种统一管理版本是一种强制的继承,让子工程承担了非常多不需要用到的依赖资源。

maven有内置的properties：project.version 和当前父工程version一致的一个值。

聚合特性

场景

有依赖，有继承关系，一个团队开发项目时候,一定多模块管理的，多人协作开发，使用maven管理项目关系的。项目结构：

a1,a2,b1,b2是项目中4个人共同并行开发的.每个项目都是一个应用的web程序,所以目的都是打成jar包,运行java启动命令。

java -jar a1.jar、java -jar a2.jar、java -jar b1.jar、java -jar b2.jar

每个项目都要执行maven声明周期中以下几个命令：

mvn clean compile 编译、mvn clean test 测试、mvn clean package 打包

打包出现问题：b1依赖a2，在打包b1时，出现找不到依赖a2的jar包错误，但是先打包a2，再去打包b1还是会打包失败，因为在执行打包b1时，会去本地库去找a2的jar包。因此需要把a2执行mvn clean install 下载到本地库，还需要b1加载到本地库找到a2的jar包，还需要重启idea。 此场景看来打包流程相当复杂，还需要额外关心项目的依赖关系。

聚合

聚合的目的：就是为了统一执行mvn相关命令的，而不需要关心依赖关系，继承关系，聚合本身就保管了所有的多模块关系。

如何实现聚合:

1. 挑选一个聚合工程，聚合工程packaging类型是pom(和父工程要求是一致的)
2. 聚合工程来实现modules配置。指向被聚合的工程(idea在创建工程时,自动实现的)。

maven-parent-demo 顶级父工程中

<modules>
    <module>child-a</module>
    <module>child-b</module>
</modules>

child-a 二级父工程中

<modules>
    <module>a1</module>
    <module>a2</module>
</modules>

如果idea版本不同,在创建项目时,聚合的配置有所区别,有可能在顶级父工程中,聚合了所有人 

配置完上述两部操作，只需要对聚合工程执行mvn命令，统一对被聚合工程执行相同的命令，而且满足依赖关系。

对父工程(maven-parent-demo)执行 mvn clean package -X 打包成功。

 聚合总结

• 意义：统一多模块mvn命令和顺序的执行。
• 实现：聚合工程packaging类型pom，指向module被聚合工程。
• 本质：pom文件加载的顺序,通过modules关联起来了。