参考笔记：
https://www.wolai.com/arAiYJYCr6Kkfi2kZ8HxE8

1. Maven 概述

1.1 什么是 Maven

Maven 是 Apache 软件基金会组织维护的一款专门为 Java 项目提供构建和依赖管理支持的工具。
在这里插入图片描述

Maven 作为依赖管理工具
- jar 包的管理
- jar 包的来源
- jar 包之间的依赖关系
Maven 作为构建管理工具
- 脱离IDE环境进行构建
  使用maven命令进行构建
- 使用IDE环境进行构建
  使用IDEA等集成开发环境进行配置并构建

1.2 构建

1.2.1 Java 项目开发过程中，构建指的是使用『原材料生产产品』的过程：

原材料
- Java 源代码
- 基于 HTML 的 Thymeleaf 文件
- 图片
- 配置文件
- ……
产品
- 一个可以在服务器上运行的项目

1.2.2 构建过程包含的主要的环节：

清理：删除上一次构建的结果，为下一次构建做好准备
编译：Java 源程序编译成 *.class 字节码文件
测试：运行提前准备好的测试程序
报告：针对刚才测试的结果生成一个全面的信息
打包
- Java工程：jar包
- Web工程：war包
安装：把一个 Maven 工程经过打包操作生成的 jar 包或 war 包存入Maven的本地仓库
部署
- 部署 jar 包：把一个 jar 包部署到 Nexus 私服服务器上
- 部署 war 包：借助相关 Maven 插件（例如 cargo），将 war 包部署到 Tomcat 服务器上

1.3 依赖

如果 A 工程里面用到了 B 工程的类、接口、配置文件等等这样的资源，那么我们就可以说 A 依赖 B。例如：

junit-4.12 依赖 hamcrest-core-1.3
thymeleaf-3.0.12.RELEASE 依赖 ognl-3.1.26
- ognl-3.1.26 依赖 javassist-3.20.0-GA
thymeleaf-3.0.12.RELEASE 依赖 attoparser-2.0.5.RELEASE
thymeleaf-3.0.12.RELEASE 依赖 unbescape-1.1.6.RELEASE
thymeleaf-3.0.12.RELEASE 依赖 slf4j-api-1.7.26

依赖管理中要解决的具体问题：

jar 包的下载：使用 Maven 之后，jar 包会从规范的远程仓库下载到本地
jar 包之间的依赖：通过依赖的传递性自动完成
jar 包之间的冲突：通过对依赖的配置进行调整，让某些jar包不会被导入

1.4 Maven 的工作机制

在这里插入图片描述

2. Maven 的配置与应用

2.1 Maven 配置与环境变量

2.1.1 Maven 官网地址与下载

首页：
Maven – Welcome to Apache Maven(opens new window)

下载页面：
Maven – Download Apache Maven(opens new window)
在这里插入图片描述

2.1.2 Maven 的目录结构

在这里插入图片描述

在解压目录中，我们需要着重关注 Maven 的核心配置文件：conf/settings.xml

2.1.3 指定 Maven 的本地仓库

本地仓库默认值：用户家目录/.m2/repository。由于本地仓库的默认位置是在用户的家目录下，而家目录往往是在 C 盘，也就是系统盘。将来 Maven 仓库中 jar 包越来越多，仓库体积越来越大，可能会拖慢 C 盘运行速度，影响系统性能。所以建议将 Maven 的本地仓库放在其他盘符下。修改Maven 的核心配置文件：conf/settings.xml，配置方式如下：

<!-- localRepository
| The path to the local repository maven will use to store artifacts.
|
| Default: ${user.home}/.m2/repository
<localRepository>/path/to/local/repo</localRepository>
-->
<localRepository>D:\maven-repository</localRepository>

本地仓库这个目录，我们手动创建一个空的目录即可。
记住：一定要把 localRepository 标签从注释中拿出来。
注意：本地仓库本身也需要使用一个非中文、没有空格的目录。

2.1.4 配置阿里云提供的镜像仓库

修改Maven 的核心配置文件：conf/settings.xml，配置方式如下：
将原有的例子配置注释掉

<!-- <mirror>
  <id>maven-default-http-blocker</id>
  <mirrorOf>external:http:*</mirrorOf>
  <name>Pseudo repository to mirror external repositories initially using HTTP.</name>
  <url>http://0.0.0.0/</url>
  <blocked>true</blocked>
</mirror> -->

加入我们的配置

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

2.1.5 配置 Maven 工程的基础 JDK 版本

修改Maven 的核心配置文件：conf/settings.xml，配置方式如下：

  <profile>
    <id>jdk-1.8</id>
    <activation>
    <activeByDefault>true</activeByDefault>
    <jdk>1.8</jdk>
    </activation>
    <properties>
    <maven.compiler.source>1.8</maven.compiler.source>
    <maven.compiler.target>1.8</maven.compiler.target>
    <maven.compiler.compilerVersion>1.8</maven.compiler.compilerVersion>
    </properties>
  </profile>

2.1.6 检查 JAVA_HOME 环境变量配置

参照 JAVA 学习笔记配置，不再赘述。

2.1.7 配置 MAVEN_HOME

在这里插入图片描述

2.1.8 配置 PATH

在这里插入图片描述

2.1.9 验证配置的结果

C:\Users\Administrator>mvn -v
Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
Maven home: D:\software\apache-maven-3.8.4
Java version: 1.8.0_141, vendor: Oracle Corporation, runtime: D:\software\Java\jre
Default locale: zh_CN, platform encoding: GBK
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

2.2 Maven 应用

2.2.1 Maven 坐标

在数学中使用 x、y、z 三个『向量』作为空间的坐标系，可以在『空间』中唯一的定位到一个『点』。
在这里插入图片描述
在 Maven 中，使用 groupId、artifactId、version 来确定唯一构件。

groupId：公司或组织域名的倒序，通常也会加上项目名称
- 例如：com.atguigu.maven
artifactId：模块的名称，将来作为 Maven 工程的工程名
version：模块的版本号，根据自己的需要设定
- 例如：SNAPSHOT 表示快照版本，正在迭代过程中，不稳定的版本
- 例如：RELEASE 表示正式版本

举例：

groupId：com.atguigu.maven
artifactId：pro01-atguigu-maven
version：1.0-SNAPSHOT

坐标：

  <groupId>javax.servlet</groupId>
  <artifactId>servlet-api</artifactId>
  <version>2.5</version>

上面坐标对应的 jar 包在 Maven 本地仓库中的位置：

Maven本地仓库根目录\javax\servlet\servlet-api\2.5\servlet-api-2.5.jar

一定要学会根据坐标到本地仓库中找到对应的 jar 包。

2.2.2 Maven 在本地的三个目录

★ Maven 核心程序：中军大帐
★ Maven 本地仓库：兵营
★ 本地工作空间：战场

2.2.3 Maven 的相关命令

mvn archetype:generate

Choose a number or apply filter (format: [groupId:]artifactId, case sensitive contains): 7:【直接回车，使用默认值】

Define value for property 'groupId': com.atguigu.maven

Define value for property 'artifactId': pro01-maven-java

Define value for property 'version' 1.0-SNAPSHOT: :【直接回车，使用默认值】

Define value for property 'package' com.atguigu.maven: :【直接回车，使用默认值】

Confirm properties configuration: groupId: com.atguigu.maven artifactId: pro01-maven-java version: 1.0-SNAPSHOT package: com.atguigu.maven Y: :【直接回车，表示确认。如果前面有输入错误，想要重新输入，则输入 N 再回车。】

mvn clean 效果：删除 target 目录
mvn compile 效果：主程序编译
- 主体程序编译结果存放的目录：target/classes
mvn test-compile 效果：测试程序编译
- 测试程序编译结果存放的目录：target/test-classes
mvn test
- 测试的报告存放的目录：target/surefire-reports
mvn package
- 打包的结果 - jar 包，存放的目录：target
- 打包的结果 - war 包，存放的目录：target
mvn install
- 安装的效果是将本地构建过程中生成的 jar、war 包存入 Maven 本地仓库。这个 jar、war 包在 Maven 仓库中的路径是根据它的坐标生成的。
mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-webapp -DarchetypeVersion=1.4
- 参数 archetypeGroupId、archetypeArtifactId、archetypeVersion 用来指定现在使用的 maven-archetype-webapp 的坐标。

2.2.4 pom.xml 文件解读

`文件解读`

  <!-- 当前Maven工程的坐标 -->
  <groupId>com.atguigu.maven</groupId>
  <artifactId>pro01-maven-java</artifactId>
  <version>1.0-SNAPSHOT</version>
  
  <!-- 当前Maven工程的打包方式，可选值有下面三种： -->
  <!-- jar：表示这个工程是一个Java工程  -->
  <!-- war：表示这个工程是一个Web工程 -->
  <!-- pom：表示这个工程是“管理其他工程”的工程 -->
  <packaging>jar</packaging>

  <name>pro01-maven-java</name>
  <url>http://maven.apache.org</url>

  <properties>
  <!-- 工程构建过程中读取源码时使用的字符集 -->
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  </properties>

  <!-- 当前工程所依赖的jar包 -->
  <dependencies>
  <!-- 使用dependency配置一个具体的依赖 -->
    <dependency>
  
    <!-- 在dependency标签内使用具体的坐标依赖我们需要的一个jar包 -->
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.12</version>
    
    <!-- scope标签配置依赖的范围 -->
      <scope>test</scope>
    </dependency>
  </dependencies>

<!-- 配置对Java工程pro01-maven-java的依赖 -->
<!-- 具体的配置方式：在dependency标签内使用坐标实现依赖 -->
<dependency>
  <groupId>com.atguigu.maven</groupId>
  <artifactId>pro01-maven-java</artifactId>
  <version>1.0-SNAPSHOT</version>
</dependency>

依赖的范围

	main目录（空间）	test目录（空间）	开发过程（时间）	部署到服务器（时间）
compile	有效	有效	有效	有效
test	无效	有效	有效	无效
provided	有效	有效	有效	无效

`依赖的传递性`

在 A 依赖 B，B 依赖 C 的前提下，C 是否能够传递到 A，取决于 B 依赖 C 时使用的依赖范围。

B 依赖 C 时使用 compile 范围：可以传递
B 依赖 C 时使用 test 或 provided 范围：不能传递，所以需要这样的 jar 包时，就必须在需要的地方明确配置依赖才可以。

`依赖的排除`

当 A 依赖 B，B 依赖 C 而且 C 可以传递到 A 的时候，A 不想要 C，需要在 A 里面把 C 排除掉。而往往这种情况都是为了避免 jar 包之间的冲突。
在这里插入图片描述

<dependency>
  <groupId>com.atguigu.maven</groupId>
  <artifactId>pro01-maven-java</artifactId>
  <version>1.0-SNAPSHOT</version>
  <scope>compile</scope>
  <!-- 使用excludes标签配置依赖的排除  -->
  <exclusions>
    <!-- 在exclude标签中配置一个具体的排除 -->
    <exclusion>
      <!-- 指定要排除的依赖的坐标（不需要写version） -->
      <groupId>commons-logging</groupId>
      <artifactId>commons-logging</artifactId>
    </exclusion>
  </exclusions>
</dependency>

`继承`

Maven工程之间，A 工程继承 B 工程

B 工程：父工程
A 工程：子工程

本质上是 A 工程的 pom.xml 中的配置继承了 B 工程中 pom.xml 的配置。
在父工程中统一管理项目中的依赖信息，具体来说是管理依赖信息的版本。

它的背景是：

对一个比较大型的项目进行了模块拆分。
一个 project 下面，创建了很多个 module。
每一个 module 都需要配置自己的依赖信息。

它背后的需求是：

在每一个 module 中各自维护各自的依赖信息很容易发生出入，不易统一管理。
使用同一个框架内的不同 jar 包，它们应该是同一个版本，所以整个项目中使用的框架版本需要统一。
使用框架时所需要的 jar 包组合（或者说依赖信息组合）需要经过长期摸索和反复调试，最终确定一个可用组合。这个耗费很大精力总结出来的方案不应该在新的项目中重新摸索。

通过在父工程中为整个项目维护依赖信息的组合既保证了整个项目使用规范、准确的 jar 包；又能够将以往的经验沉淀下来，节约时间和精力。

  <groupId>com.atguigu.maven</groupId>
  <artifactId>pro03-maven-parent</artifactId>
  <version>1.0-SNAPSHOT</version>

  <!-- 当前工程作为父工程，它要去管理子工程，所以打包方式必须是 pom -->
  <packaging>pom</packaging>

只有打包方式为 pom 的 Maven 工程能够管理其他 Maven 工程。打包方式为 pom 的 Maven 工程中不写业务代码，它是专门管理其他 Maven 工程的工程。

父工程的 pom.xml 被添加的内容：

<modules>  
  <module>pro04-maven-module</module>
  <module>pro05-maven-module</module>
  <module>pro06-maven-module</module>
</modules>

子工程的 pom.xml 被添加的内容：

<!-- 使用parent标签指定当前工程的父工程 -->
<parent>
  <!-- 父工程的坐标 -->
  <groupId>com.atguigu.maven</groupId>
  <artifactId>pro03-maven-parent</artifactId>
  <version>1.0-SNAPSHOT</version>
</parent>

<!-- 子工程的坐标 -->
<!-- 如果子工程坐标中的groupId和version与父工程一致，那么可以省略 -->
<!-- <groupId>com.atguigu.maven</groupId> -->
<artifactId>pro04-maven-module</artifactId>
<!-- <version>1.0-SNAPSHOT</version> -->

在父工程中配置依赖的统一管理

<!-- 使用dependencyManagement标签配置对依赖的管理 -->
<!-- 被管理的依赖并没有真正被引入到工程 -->
<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>spring-core</artifactId>
      <version>4.0.0.RELEASE</version>
    </dependency>
    <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>spring-beans</artifactId>
      <version>4.0.0.RELEASE</version>
    </dependency>
    <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>spring-context</artifactId>
      <version>4.0.0.RELEASE</version>
    </dependency>
    <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>spring-expression</artifactId>
      <version>4.0.0.RELEASE</version>
    </dependency>
    <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>spring-aop</artifactId>
      <version>4.0.0.RELEASE</version>
    </dependency>
  </dependencies>
</dependencyManagement>

子工程中引用那些被父工程管理的依赖
关键点：省略版本号

<!-- 子工程引用父工程中的依赖信息时，可以把版本号去掉。  -->
<!-- 把版本号去掉就表示子工程中这个依赖的版本由父工程决定。 -->
<!-- 具体来说是由父工程的dependencyManagement来决定。 -->
<dependencies>
  <dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-core</artifactId>
  </dependency>
  <dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-beans</artifactId>
  </dependency>
  <dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-context</artifactId>
  </dependency>
  <dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-expression</artifactId>
  </dependency>
  <dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-aop</artifactId>
  </dependency>
</dependencies>

在父工程中升级依赖信息的版本

      <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-beans</artifactId>
        <version>4.1.4.RELEASE</version>
      </dependency>

然后在子工程中运行mvn dependency:list，效果如下：

[INFO] org.springframework:spring-aop:jar:4.1.4.RELEASE:compile  
[INFO] org.springframework:spring-core:jar:4.1.4.RELEASE:compile  
[INFO] org.springframework:spring-context:jar:4.1.4.RELEASE:compile  
[INFO] org.springframework:spring-beans:jar:4.1.4.RELEASE:compile  
[INFO] org.springframework:spring-expression:jar:4.1.4.RELEASE:compile

在父工程中声明自定义属性

<!-- 通过自定义属性，统一指定Spring的版本 -->
<properties>
  <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  
  <!-- 自定义标签，维护Spring版本数据 -->
  <atguigu.spring.version>4.3.6.RELEASE</atguigu.spring.version>
</properties>

在需要的地方使用${}的形式来引用自定义的属性名：

      <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-core</artifactId>
        <version>${atguigu.spring.version}</version>
      </dependency>

真正实现“一处修改，处处生效”。
在这里插入图片描述

2.2.5 约定的目录结构

java 项目
在这里插入图片描述
java web 项目

另外还有一个 target 目录专门存放构建操作输出的结果。

Maven 为了让构建过程能够尽可能自动化完成，所以必须约定目录结构的作用。例如：Maven 执行编译操作，必须先去 Java 源程序目录读取 Java 源代码，然后执行编译，最后把编译结果存放在 target 目录。
Maven 对于目录结构这个问题，没有采用配置的方式，而是基于约定。这样会让我们在开发过程中非常方便。如果每次创建 Maven 工程后，还需要针对各个目录的位置进行详细的配置，那肯定非常麻烦。
目前开发领域的技术发展趋势就是：约定大于配置，配置大于编码。

2.2.6 其他概念

1、生命周期
①作用
为了让构建过程自动化完成，Maven 设定了三个生命周期，生命周期中的每一个环节对应构建过程中的一个操作。

②三个生命周期

生命周期名称	作用	各个环节
Clean	清理操作相关	pre-clean clean post-clean
Site	生成站点相关	pre-site site post-site deploy-site
Default	主要构建过程	validate generate-sources process-sources generate-resources process-resources 复制并处理资源文件，至目标目录，准备打包。 compile 编译项目 main 目录下的源代码。 process-classes generate-test-sources process-test-sources generate-test-resources process-test-resources 复制并处理资源文件，至目标测试目录。 test-compile 编译测试源代码。 process-test-classes test 使用合适的单元测试框架运行测试。这些测试代码不会被打包或部署。 prepare-package package 接受编译好的代码，打包成可发布的格式，如JAR。 pre-integration-test integration-test post-integration-test verify install将包安装至本地仓库，以让其它项目依赖。 deploy将最终的包复制到远程的仓库，以让其它开发人员共享；或者部署到服务器上运行（需借助插件，例如：cargo）。

③特点

前面三个生命周期彼此是独立的。
在任何一个生命周期内部，执行任何一个具体环节的操作，都是从本周期最初的位置开始执行，直到指定的地方。（本节记住这句话就行了，其他的都不需要记）

Maven 之所以这么设计其实就是为了提高构建过程的自动化程度：让使用者只关心最终要干的即可，过程中的各个环节是自动执行的。

2、插件和目标

①插件
Maven 的核心程序仅仅负责宏观调度，不做具体工作。具体工作都是由 Maven 插件完成的。例如：编译就是由 maven-compiler-plugin-3.1.jar 插件来执行的。

②目标
一个插件可以对应多个目标，而每一个目标都和生命周期中的某一个环节对应。
Default 生命周期中有 compile 和 test-compile 两个和编译相关的环节，这两个环节对应 compile 和 test-compile 两个目标，而这两个目标都是由 maven-compiler-plugin-3.1.jar 插件来执行的。

3、仓库

本地仓库：在当前电脑上，为电脑上所有 Maven 工程服务
远程仓库：需要联网
- 局域网：我们自己搭建的 Maven 私服，例如使用 Nexus 技术。
- Internet
  - 中央仓库
  - 镜像仓库：内容和中央仓库保持一致，但是能够分担中央仓库的负载，同时让用户能够就近访问提高下载速度，例如：Nexus aliyun

建议：不要中央仓库和阿里云镜像混用，否则 jar 包来源不纯，彼此冲突。
专门搜索 Maven 依赖信息的网站：https://mvnrepository.com/