maven聚合工程详解

本篇文章重点针对这几个问题进行讲解:

  1. Maven继承
  2. 使用IDEA搭建Maven父子工程
  3. 使用IDEA搭建Maven聚合工程
  4. Maven父子工程和聚合工程的区别

一、Maven继承

Maven 在设计时,借鉴了 Java 面向对象中的继承思想,提出了 POM 继承思想。

当一个项目包含多个模块时,可以在该项目中再创建一个父模块,并在其 POM 中声明依赖,其他模块的 POM 可通过继承父模块的 POM 来获得对相关依赖的声明。对于父模块而言,其目的是为了消除子模块 POM 中的重复配置,其中不包含有任何实际代码,因此父模块 POM 的打包类型(packaging)必须是 pom

继承所涉及到的标签如下:

在这里插入图片描述

二、idea搭建父子工程

1.新建父工程,这里就正常选择springboot就可以

2.idea会让你选择需要引入的框架,这里我们直接下一步就可以

3.删除无用文件

4.将pom.xml的packaging标签改为pom

新建springboot项目默认继承了spring-boot-starter-parent,spring-boot-starter-parent当中给我们提供了大量的配置,很多框架的版本号都有,而我们在继承过后很多框架就不需要声明版本号了,既然是官方提供的,那也就不用担心框架与框架版本不适配的问题了。

这里为了做父子依赖继承的测试,我引用了一个lang3的包,完整的依赖如下:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
	<modelVersion>4.0.0</modelVersion>
	<parent>
		<groupId>org.springframework.boot</groupId>
		<artifactId>spring-boot-starter-parent</artifactId>
		<version>2.7.10</version>
		<relativePath/>
		<!-- lookup parent from repository -->
	</parent>
	<groupId>com.gzl.cn</groupId>
	<artifactId>paren-demo</artifactId>
	<version>0.0.1-SNAPSHOT</version>
	<name>paren-demo</name>
	<description>paren-demo</description>
	<packaging>pom</packaging>
	<properties>
		<java.version>1.8</java.version>
	</properties>
	<!--依赖管理-->
	<dependencyManagement>
		<dependencies>
			<dependency>
				<groupId>cn.hutool</groupId>
				<artifactId>hutool-all</artifactId>
				<version>5.8.18</version>
			</dependency>
		</dependencies>
	</dependencyManagement>

	<dependencies>
		<dependency>
			<groupId>org.apache.commons</groupId>
			<artifactId>commons-lang3</artifactId>
			<version>3.12.0</version>
		</dependency>
	</dependencies>

</project>

5.新建子项目

这里<relativePath/>的尽量去掉,不然可能会报异常!子模块的 POM 中,当前模块的 groupId 和 version 元素可以省略,但这并不意味着当前模块没有 groupId 和 version,子模块会隐式的从父模块中继承这两个元素,即由父模块控制子模块的公司组织 id 以及版本,这样可以简化 POM 的配置。

6.现在存在一个问题,项目没有被idea识别成maven项目
(1)首先点击工具栏最左边的 Help 再点击 Find Action ;或者使用快捷键 Ctrl+Shift+A
(2)接着在输入框中输入 maven projects ,会弹出一个 Add Maven Projects 选项,点击即可,会弹出下图的弹窗

(3)最后,选择本项目的 pom.xml 点击 OK 即可解决!

观察如下:

三、可继承的 POM 元素

四、Maven聚合

上面项目只是新建了一个子项目,在实际的开发过程中,我们所接触的项目一般都由多个模块组成。在构建项目时,如果每次都按模块一个一个地进行构建会十分得麻烦,Maven 的聚合功能很好的解决了这个问题。

使用 Maven 聚合功能对项目进行构建时,需要在该项目中额外创建一个的聚合模块,然后通过这个模块构建整个项目的所有模块。聚合模块仅仅是帮助聚合其他模块的工具,其本身并无任何实质内容,因此聚合模块中只有一个 POM 文件,不像其他的模块一样包含 src/main/java、src/test/java 等多个目录。

与父模块相似,聚合模块的打包方式(packaging)也是 pom,用户可以在其 POM 中通过 modules 下的 module 子元素来添加需要聚合的模块的目录路径。

<modules>
	<module>user-service</module>
</modules>

五、idea搭建聚合工程

还是拿上面的项目作为示例,这是没有聚合前的样子:paren-demo和user-service是同级的

修改 Root 模块 POM 的配置如下:

这时候对父工程进行clean install的时候会发现,他会连带着子工程一块进行构建

聚合模块在构建时,Maven 会先解析聚合模块的 POM、分析需要构建的模块,并根据这些模块之间的关系计算出构建顺序,然后根据这个顺序依次构建各个模块。

构建完成后输出的是一个项目构建的小结报告,该报告中包括各个模块构建成功与否、构建花费的时间、以及整个构建构成所花费的时间等信息。

六、继承和聚合的关系

Maven 的继承和聚合的目的不同,继承的目的是为了消除 POM 中的重复配置,聚合的目的是为了方便快速的构建项目。

  • 对于继承中的父模块来说,它跟本不知道那些模块继承了它,但子模块都知道自己的父模块是谁。
  • 对于聚合模块来说,它知道哪些模块被聚合了,但那些被聚合的模块根本不知道聚合模块的存在。

两者在结构和形式上还是有一定的共同点的,最直观的就是两者的打包方式都是 pom,两者除了 POM 外都没有实际的代码内容。

注意:没有继承照样可以使用聚合,没有聚合照样也可以使用继承,两个之间并没有依赖关系!

在实际开发当中一般都是聚合和继承一块使用的,使用idea可以快速的创建,如下:

虽然使用这种方式创建maven项目可以帮我们省去修改pom的时间,但是我们还需要手动修改springboot启动类,以及添加resources文件夹。

七、dependencyManagement

我们知道,子模块可以通过继承获得父模块中声明的全部依赖,这样虽然避免了在各个子模块 POM 中重复进行依赖声明,但也极有可能造成子模块中引入一些不必要的依赖。为此 Maven 引入了 dependencyManagement 来对依赖进行管理。

Maven 可以通过 dependencyManagement 元素对依赖进行管理,它具有以下 2 大特性:

  • 在该元素下声明的依赖不会实际引入到模块中,只有在 dependencies 元素下同样声明了该依赖,才会引入到模块中。
  • 该元素能够约束 dependencies 下依赖的使用,即 dependencies 声明的依赖若未指定版本,则使用 dependencyManagement 中指定的版本,否则将覆盖 dependencyManagement 中的版本。

在实际的开发过程中,dependencyManagement 很少会单独使用,通常它需要与 Maven 继承或依赖范围 import 配合使用才能展现它的优势。

比如在父依赖当中使用如下pom:

<dependencyManagement>
	<dependencies>
		<dependency>
			<groupId>cn.hutool</groupId>
			<artifactId>hutool-all</artifactId>
			<version>5.8.18</version>
		</dependency>
	</dependencies>
</dependencyManagement>

这时候子模块就可以只通过groupId和artifactId来引入框架了。可以省去了 version 和 scope。

<dependencies>
	<dependency>
		<groupId>cn.hutool</groupId>
		<artifactId>hutool-all</artifactId>
	</dependency>
</dependencies>

使用这种依赖管理机制似乎并不能减少太多 POM 配置,但我们仍然推荐使用这种方式,其原因主要有 2 个:

  • 在父模块中使用 dependencyManagement声明依赖能够统一项目内依赖的版本,子模块无须声明版本,也就不会出现多个子模块使用同一依赖项版本不一致的情况,降低依赖冲突的几率。
  • dependencyManagement 声明的依赖不会被实际引入,子模块需要什么依赖就自己引入,增加了灵活性,避免引入一些不必要的依赖

import 依赖范围只能与 dependencyManagement 元素配合使用才会有效,其功能是将目标 pom.xml 中的 dependencyManagement 配置导入合并到当前 pom.xml 的 dependencyManagement 中。

关于spring-boot-dependencies不是很了解的可以看一下这篇文章:https://blog.csdn.net/weixin_43888891/article/details/130520345

<dependencyManagement>
	 <dependencies>
		<dependency>
			 <groupId>org.springframework.boot</groupId>
			 <artifactId>spring-boot-dependencies</artifactId>
			 <version>2.7.10</version>
			 <type>pom</type>
			 <scope>import</scope>
		 </dependency>
	</dependencies>
</dependencyManagement>

以上配置中,由于 import 依赖范围的特殊性,一般都是指向打包类型为 pom 的模块,所以 type 元素的值一般为 pom。

例如spring-boot-dependencies当中有很多dependencyManagement管理的项目,他会将dependencyManagement当中所有依赖管理导入到当前项目。

八、pluginManagement

pluginManagement 元素与 dependencyManagement 元素的原理十分相似,在 pluginManagement 元素中可以声明插件及插件配置,但不会发生实际的插件调用行为,只有在 POM 中配置了真正的 plugin 元素,且其 groupId 和 artifactId 与 pluginManagement 元素中配置的插件匹配时,pluginManagement 元素的配置才会影响到实际的插件行为。

当项目中的多个模块存在相同的插件时,应当将插件配置移动到父模块的 pluginManagement 元素中。即使各个模块对于同一插件的具体配置不尽相同,也应当在父模块中使用 pluginManagement 元素对插件版本进行统一声明。

在spring-boot-dependencies给我们提供了大量的插件版本管理,这也就是我们在springboot项目当中引用插件有时候根本不需要声明版本号的原因:

springboot父pom默认配置如下:

  • delimiter:就是更改变量取值的形式,上面也有提到过。
  • propertiesEncoding:就是字符编码

然后我又在自己的项目当中声明了maven-resources-plugin插件:

<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-resources-plugin</artifactId>
	<version>3.2.0</version>
	<configuration>
	  <nonFilteredFileExtensions>
		 <!--不应用过滤的其他文件扩展名(已定义的有:jpg, jpeg, gif, bmp, png)-->
		  <nonFilteredFileExtension>xls</nonFilteredFileExtension>
		  <nonFilteredFileExtension>xlsx</nonFilteredFileExtension>
	   </nonFilteredFileExtensions>
	</configuration>
</plugin>

这里有一点需要注意,springboot在父pom的pluginManagement设置了maven-resources-plugin,而我们又在项目当中声明了maven-resources-plugin,最终他生效的是父pom+我们声明的配置:

通过mvn help:effective-pom命令即可查看生效的pom

猜你喜欢

转载自blog.csdn.net/weixin_43888891/article/details/130732237