一、Maven简介
1、为什么学习Maven
1.1、Maven是一个依赖管理工具
- 随着我们使用越来越多的框架，或者框架封装程度越来越高，项目中使用的jar包也越来越多。项目中，一个模块里面用到上百个jar包是非常正常的。而如果使用 Maven 来引入这些 jar 包只需要配置三个“依赖”：
<!-- Nacos 服务注册发现启动器 -->
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>
<!-- web启动器依赖 -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<!-- 视图模板技术 thymeleaf -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-thymeleaf</artifactId>
</dependency>
- jar包所属技术的官网通常是英文界面，网站的结构又不尽相同，甚至找到下载链接还发现需要通过特殊的工具下载。第三方网站提供下载时会出现不规范，在使用过程中会出现各种问题。使用 Maven 后，依赖对应的 jar 包能够自动下载，方便、快捷又规范。
- 在web工程中，jar包必须存放在指定位置（lib）。在使用Maven之后，通过配置依赖(jar包)的坐标，查找本地仓库中相应jar包，若本地仓库没有，则统一从镜像网站或中央仓库中下载。
- 框架中使用的 jar 包，不仅数量庞大，而且彼此之间存在错综复杂的依赖关系。这种依赖关系是极其复杂的，人工进行梳理是非常浪费时间和精力的，而使用 Maven 则几乎不需要管理这些关系，极个别的地方调整一下即可，极大的减轻了我们的工作量。
1.2、Maven是一个构建工具
Maven可以通过一些插件轻松的帮我们进行项目的构建（clean、package、compile），极大增加了我们的工作效率。
二、基于IDEA的Maven项目
2.1、Maven工程GAVP的概念
- Maven工程相对之前的项目，多出一组gavp属性，gav需要我们在创建项目的时候指定，p有默认值。
- Maven 中的 GAVP 是指 GroupId、ArtifactId、Version、Packaging 等四个属性的缩写，其中前三个是必要的，而 Packaging 属性为可选项。这四个属性主要为每个项目在maven仓库中做一个标识，类似人的姓-名！有了具体标识，方便后期项目之间相互引用依赖等！
GAV遵循一下规则：
- GroupID 格式：com.{公司/BU }.业务线.[子业务线]，最多 4 级。说明：{公司/BU} 例如：alibaba/taobao等 BU 一级；子业务线可选。正例：com.taobao.maven
- ArtifactID 格式：产品线名-模块名。语义不重复不遗漏，先到仓库中心去查证一下。
- Version版本号格式推荐：主版本号.次版本号.修订号
Packaging定义规则：
- packaging 属性为 jar（默认值），代表普通的Java工程，打包以后是.jar结尾的文件。
- packaging 属性为 war，代表Java的web工程，打包以后.war结尾的文件。
- packaging 属性为 pom，代表不会打包，用来做继承的父工程。
2.2、Maven工程项目结构说明
三、Maven项目的构建
3.1、构建的概念
项目构建是指将源代码、依赖库和资源文件等转换成可执行或可部署的应用程序的过程，在这个过程中包括编译源代码、链接依赖库、打包和部署等多个步骤。
3.2、 构建的基本命令
- mvn compile：编译项目，生成target文件
- mvn package：打包项目，生成jar或war文件
- mvn clean：清理编译或打包后的项目结构
- mvn install：打包后上传到maven本地仓库
- mvn deploy：只打包，上传到maven私服仓库
- mvn site：生成站点
- mvn test：执行测试源码
注：maven可提供可视化构建，无需在终端进行构建！
四、Maven依赖管理
4.1、 依赖管理概念
我们通过定义 POM 文件，Maven 能够自动解析项目的依赖关系，并通过 Maven 仓库自动下载和管理依赖，从而避免了手动下载和管理依赖的繁琐工作和可能引发的版本冲突问题。
4.2、 Maven工程依赖管理配置
文件位置：pom.xml
依赖信息查询方式（在安装依赖前需去官网查看是否存在该依赖）：https://mvnrepository.com/
<dependencies>
<!-- 引入具体的依赖包 -->
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.17</version>
<!-- 依赖范围 -->
<scope>runtime</scope>
</dependency>
</dependencies>
4.3、 依赖范围
通过设置坐标的依赖范围(scope)，可以设置 对应jar包的作用范围：编译环境、测试环境、运行环境（前三种常用）。
- compile：编译依赖范围，scope 元素的缺省值。使用此依赖范围的 Maven 依赖，对于三种 classpath均有效，即该 Maven 依赖在上述三种 classpath 均会被引入。例如，log4j 在编译、测试、运行过程都是必须的。
- test：测试依赖范围。使用此依赖范围的 Maven 依赖，只对测试 classpath 有效。例如，Junit 依赖只有在测试阶段才需要。
- provided：已提供依赖范围。使用此依赖范围的 Maven 依赖，只对编译 classpath 和测试 classpath 有效。例如，servlet-api 依赖对于编译、测试阶段而言是需要的，但是运行阶段，由于外部容器（例Tomcat）已经提供，故不需要 Maven 重复引入该依赖。
- runtime：运行时依赖范围。使用此依赖范围的 Maven 依赖，只对测试 classpath、运行 classpath 有效。例如，JDBC 驱动实现依赖，其在编译时只需 JDK 提供的 JDBC 接口即可，只有测试、运行阶段才需要实现了 JDBC 接口的驱动。
- system：系统依赖范围，其效果与 provided 的依赖范围一致。其用于添加非 Maven 仓库的本地依赖，通过依赖元素 dependency 中的 systemPath 元素指定本地依赖的路径。鉴于使用其会导致项目的可移植性降低，一般不推荐使用。
- import：导入依赖范围，该依赖范围只能与 dependencyManagement 元素配合使用，其功能是将目标 pom.xml 文件中 dependencyManagement 的配置导入合并到当前 pom.xml 的 dependencyManagement 中。
五、Maven依赖传递和依赖冲突
5.1、 Maven依赖传递特性
5.1.1、 概念
假如有Maven项目A，项目B依赖A，项目C依赖B。那么我们可以说 C依赖A。也就是说，依赖的关系为：C—>B—>A， 那么我们执行项目C时，会自动把B、A都下载导入到C项目的jar包文件夹中，这就是依赖的传递性。
5.1.2、传递的原则
在 A 依赖 B，B 依赖 C 的前提下，C 是否能够传递到 A，取决于 B 依赖 C 时使用的依赖范围以及配置
- B 依赖 C 时使用 compile 范围：可以传递
- B 依赖 C 时使用 test 或 provided 范围：不能传递，所以需要这样的 jar 包时，就必须在需要的地方明确配置依赖才可以。
- B 依赖 C 时，若配置了以下标签，则不能传递
<dependency>
<groupId>com.alibaba</groupId>
<artifactId>druid</artifactId>
<version>1.2.15</version>
<optional>true</optional> #禁止
</dependency>
5.1.3、 依赖传递终止
- 非compile范围进行依赖传递。
- 使用optional配置终止传递。
- 依赖冲突（传递的依赖已经存在）。
5.2、Maven依赖冲突特性
当直接引用或者间接引用出现了相同的jar包， 一个项目就会出现相同的重复jar包，这就算作冲突！依赖冲突避免出现重复依赖，并且终止依赖传递！
maven自动解决依赖冲突问题能力，会按照自己的原则，进行重复依赖选择。同时也提供了手动解决的冲突的方式（不推荐）。
5.2.1、自动选择原则
（1）短路优先原则（第一原则）
A—>B—>C—>D—>E—>X(version 0.0.1)
A—>F—>X(version 0.0.2)
则A依赖于X(version 0.0.2)。
（2）依赖路径长度相同情况下，则“先声明优先”（第二原则）
A—>E—>X(version 0.0.1)
A—>F—>X(version 0.0.2)
在<depencies></depencies>中，先声明的，路径相同，会优先选择！
5.2.2、 手动排出
<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>
注：optional只可在自己的工程内使用，引入别人的jar包不可采取，设置该标签后，其他工程则不能传递获得该jar包（即不参与传递）。而使用exclusion则可以手动选择是否依赖 被依赖方 的某个包。
六、 Maven工程继承和聚合关系
6.1、 Maven工程继承关系
- 概念
Maven 继承是指在 Maven 的项目中，让一个项目从另一个项目中继承配置信息的机制。继承可以让我们在多个项目中共享同一配置信息，简化项目的管理和维护工作。 - 需求
（1）在每一个 module 中各自维护各自的依赖信息很容易发生出入，不易统一管理。
（2）使用同一个框架内的不同 jar 包，它们应该是同一个版本，所以整个项目中使用的框架版本需要统一。
（3）使用框架时所需要的 jar 包组合（或者说依赖信息组合）需要经过长期摸索和反复调试，最终确定一个可用组合。这个耗费很大精力总结出来的方案不应该在新的项目中重新摸索。 - 父工程继承语法
<groupId>com.atguigu.maven</groupId>
<artifactId>pro03-maven-parent</artifactId>
<version>1.0-SNAPSHOT</version>
<!-- 当前工程作为父工程，它要去管理子工程，所以打包方式必须是 pom 不需要打包成jar、war -->
<packaging>pom</packaging>
- 子工程继承语法
<!-- 使用parent标签指定当前工程的父工程 -->
<parent>
<!-- 父工程的坐标 -->
<groupId>com.atguigu.maven</groupId>
<artifactId>pro03-maven-parent</artifactId>
<version>1.0-SNAPSHOT</version>
</parent>
<!-- 子工程的坐标 -->
<!-- 子工程坐标中的groupId和version与父工程一致，可以省略 -->
<artifactId>pro04-maven-module</artifactId>
注：若父工程使用dependencies标签进行依赖配置，则子工程会无条件进行依赖继承。若使用dependencyManagement标签配置，子工程需要进行所需依赖选择（即只省略了版本号，因为继承版本一致）。
6.2、 Maven工程聚合关系
- 聚合概念
Maven 聚合是指将多个项目组织到一个父级项目中，以便一起构建和管理的机制。聚合可以帮助我们更好地管理一组相关的子项目，同时简化它们的构建和部署过程。 - 聚合作用
（1） 管理多个子项目：通过聚合，可以将多个子项目组织在一起，方便管理和维护。
（2）构建和发布一组相关的项目：通过聚合，可以在一个命令中构建和发布多个相关的项目，简化了部署和维护工作。
（3）优化构建顺序：通过聚合，可以对多个项目进行顺序控制，避免出现构建依赖混乱导致构建失败的情况。
（4）统一管理依赖项：通过聚合，可以在父项目中管理公共依赖项和插件，避免重复定义。 - 聚合语法
父项目（modules标签）中包含的子项目列表
<project>
<groupId>com.example</groupId>
<artifactId>parent-project</artifactId>
<packaging>pom</packaging>
<version>1.0.0</version>
<modules>
<module>child-project1</module>
<module>child-project2</module>
</modules>
</project>
七、Maven私服
7.1、 Maven私服简介
Maven 私服是一种特殊的Maven远程仓库，它是架设在局域网内的仓库服务（也可部署到公网，取决于项目的保密程度等），用来代理位于外部的远程仓库（中央仓库、其他远程公共仓库）。
建立了 Maven 私服后，当局域网内的用户需要某个构件时，会按照如下顺序进行请求和下载。
（1）请求本地仓库，若本地仓库不存在所需构件，则跳转到第 2 步；
（2）请求 Maven 私服，将所需构件下载到本地仓库，若私服中不存在所需构件，则跳转到第 3 步。
（3）请求外部的远程仓库，将所需构件下载并缓存到 Maven 私服，若外部远程仓库不存在所需构件，则 Maven 直接报错。
此外，一些无法从外部仓库下载到的构件，也能从本地上传到私服供其他人使用（公司自己开发供员工使用等）。
7.2、 Maven私服的优势
（1）节省外网带宽：消除对外部远程仓库的大量重复请求（会消耗很大量的带宽），降低外网带宽压力。因为若没有私服，很多人需要去外部仓库进行下载。
（2）下载速度更快：Maven私服位于局域网内，从私服下载构建更快更稳定。
（3）便于部署第三方构件：有些构件无法从任何一个远程仓库中获得（如：公司或组织内部的私有构件、Oracle的JDBC驱动等），建立私服之后，就可以将这些构件部署到私服中，供内部Maven项目使用。
（4）提高项目的稳定性，增强对项目的控制：如果不建立私服，那么Maven项目的构件就高度依赖外部的远程仓库，若外部网络不稳定，则项目的构建过程也会变得不稳定。建立私服后，即使外部网络状况不佳甚至中断，只要私服中已经缓存了所需的构件，Maven也能够正常运行。私服软件（如：Nexus）提供了很多控制功能（如：权限管理、RELEASE/SNAPSHOT版本控制等），可以对仓库进行一些更加高级的控制。
（5） 降低中央仓库得负荷压力：由于私服会缓存中央仓库得构件，避免了很多对中央仓库的重复下载，降低了中央仓库的负荷。