Maven的标签详解篇一

概述

jar 包的规模

随着我们使用越来越多的框架，或者框架封装程度越来越高，项目中使用的jar包也越来越多。项目中，一个模块里面用到上百个jar包是非常正常的。比如下面的例子，我们只用到 SpringBoot、SpringCloud 框架中的三个功能：

• Nacos 服务注册发现
• Web 框架环境
• 图模板技术 Thymeleaf

<!-- 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>

看样子是导入了三个基础包，实际上导入了106个jar包。框架中使用的 jar 包，不仅数量庞大，而且彼此之间存在错综复杂的依赖关系。依赖关系的复杂程度，已经上升到了完全不能靠人力手动解决的程度。另外，jar 包之间有可能产生冲突。进一步增加了我们在 jar 包使用过程中的难度。但是使用 Maven 则几乎不需要管理这些关系，极个别的地方调整一下即可，极大的减轻了我们的工作量。
如图所示：

常用标签详解

models 标签

模块标签，用于聚合maven各子模块，方便项目统一管理的作用，具有父子层级关系，标签用在父层级POM中
业务场景： 一个复杂的系统包含多个模块，可用models集合的方式快速构建项目，方便管理
如图所示：

parent 标签

继承标签，功能类似java的继承作用，具有父子继承关系，标签用在子POM中
业务场景： 抽离子类公共依赖，统一控制版本号，如 spring-boot-starter-parent 使用

dependencyManagement 标签

继承自该项目的所有子项目的默认依赖信息。这部分的依赖信息不会被立即解析，而是当子项目声明一个依赖（必须描述group ID和 artifact ID信息），如果group ID和artifact ID以外的一些信息没有描述，则通过group ID和artifact ID 匹配到这里的依赖，并使用这里的依赖信息，标签用在父POM中

业务场景： 一般与 < parent > 配合使用，将父类公共依赖管理起来，按子类需要继承（加载）

distributionManagement 标签

项目分发信息，在执行mvn deploy后表示要发布的位置。有了这些信息就可以把网站部署到远程服务器或者把构件部署到远程仓库。

pluginManagement 标签

子项目可以引用的默认插件信息。该插件配置项直到被引用时才会被解析或绑定到生命周期。给定插件的任何本地配置都会覆盖这里的配置
经验总结:

• 聚合主要是为了方便快速构建项目，继承主要是为了消除重复配置；
• 对于聚合模块而言，它知道有哪些被聚合的模块，但那些被聚合的模块不知道这个聚合模块的存在；对于继承的父pom而言，它不知道有哪些子模块继承它，但那些子模块都必须知道自己的父POM是什么；
• 聚合POM与继承中的父POM的packaging都必须是pom；同时，聚合模块与继承中的父模块除了POM外，都没有实际的内容

scope 标签

Maven 项目可以分为三个阶段：编译阶段，测试阶段，运行阶段了。
通过 scope 属性，我们可以决定依赖应用是否参与以上阶段，也将会影响依赖传递。

Maven 提供 6 种 scope：

• compile

• provided

• runtime

• test

• system

• import

compile：
compile 是 Maven 默认属性，将会使依赖包参与项目的编译，测试，运行阶段。当然，项目打包之后将会包含该依赖。

provided：
provided 意味着依赖仅参与项目编译，测试的阶段。
若有如下依赖关系：
A----->B----->C
C 的 scope 为provided，C 将会参与 B 的编译，测试阶段，但是 C 不会传递给 A。如果 A 运行过程需要 C，需要自己直接引入 C 依赖。典型如 Servlet API，因为 Tomcat 等容器内部会提供。

runtime：
runtime 代表依赖不再参与项目编译阶段，只参与测试，运行阶段。若依赖不参与编译阶段，这种情况 IDE 中是无法导入相应的类的。若存在依赖类，编译过程中将会报错。
典型的例子是 JDBC 驱动包，如 mysql。
知识点：这个好处在于，只能使用 JDBC 标准接口，这样就不会与特定的数据库绑定。后续若切换数据库，只需要更换 pom，然后修改相应的参数即可。

test：
test 仅参与测试阶段的工作，典型的例子为 junit。

system：
system 与 provided 范围一致，只不过 system 需要使用 systemPath 属性指定本地路径，而 provided 将会从 Maven 仓库拉取。

import：
import 比较特殊，不会参与以上阶段运行。其只能在 dependencyManagement下使用，且 type 需要为 pom。
典型的例子为 Spring-boot 依赖。
知识点：通过这种方式，解决单继承问题，也可以更好将依赖分类。

packaging 标签

pom 属性

在父级项目中的pom.xml文件使用的packaging配置一定为pom。父级的pom文件只作项目的子模块的整合，在maven install时不会生成jar/war压缩包。

1. 通过标签来整合子模块的编译顺序（Maven引入依赖使用最短路径原则，例如a<–b<–c1.0，d<–e<–f<–c1.1，由于路径最短，最终引入的为c1.0；但路径长度相同时，则会引入先申明的依赖）。因此尽量将更加底层的service放在更先的位置优先加载依赖较为合适。
2. 将一些子项目中共用的依赖或将其版本统一写到父级配置中，以便统一管理。
3. groupId, artifactId, version能直接从父级继承，减少子项目的pom配置。

jar属性

Jar包是最为常见的打包方式，当pom文件中没有设置packaging参数时，默认使用jar方式打包。这种打包方式意味着在maven build时会将这个项目中的所有java文件都进行编译形成.class文件，且按照原来的java文件层级结构放置，最终压缩为一个jar文件。
当我们使用mvn install命令的时候，能够发现在项目中与src文件夹同级新生成了一个target文件夹，这个文件夹内的classes文件夹即为刚才提到的编译后形成的文件夹。

war属性

war包与jar包非常相似，同样是编译后的.class文件按层级结构形成文件树后打包形成的压缩包。不同的是，它会将项目中依赖的所有jar包都放在WEB-INF/lib这个文件夹下

参考

• https://blog.csdn.net/cchchunhe/article/details/89375341
• https://blog.csdn.net/weixin_43871678/article/details/121015479
• https://blog.csdn.net/imaginehero/article/details/103706732