Maven聚合与继续

聚合

   当我们一次想要构建多个项目时，而不是到每一个模块的目次下分别实行mvn命令。这个时候就必要使用到maven的聚合特性
  

• 这里第一个特殊的地方是packaging，值设置为pom。我们正常开发的其他模块中都没有声明packaging，默认使用了默认值jar，但是对于聚合模块来说，其打包方式必须为pom，否则无法构建。
  
• 元素 modules 是实现聚合的核心配置，用户可以通过在一个打包方式为pom的Maven项目中声明任意数量的module元向来实现模块的聚合，这里每一个module值都是一个当前pom的相对目次，因此一样平常来说模块所处的目次名称应当与其artifactId一致，也可以进行自定义名称更改对应的module配置就可以。
  
• 一样平常来说，为了方便用户构建项目，通常将聚合模块放在项目目次的最底层，其他模块则作为聚合模块的子目次存在，这样当用户得到源码的时候第一眼发现的就是聚合模块的pom，不消从多个模块中去探求聚合模块来构建整个项目。
  
  
  
  

继续

   当我们多个模块下存在很多雷同的配置时，比方它们都有雷同的groupId和version，有雷同的spring-core，slf4j，junit依赖，还有雷同的maven-compiler-plugin配置时。在mavne的世界中，也有类似的机制能让我们抽取出重复的配置，这就是pom的继续

  

• 上图pom中使用parent声明父模块，parent下的子元素，groupId,artifactId和version指定了父模块的坐标，这三个元素是必须的，还有一个元素relativePath表示父模块pom相对路径。当项目构建时，Maven会首先根据relativePath查抄父pom，如果找不到，再从本地仓库查找。relativePath默认值是<relativePath>../pom.xml</relativePath>，也就是说Maven默认父pom在上一层目次下。
  
• 图中我们的pipeline 这个模块并没有声明groupId和verison，这并不代表我们这个模块中没有groupId和verison。实际上我们这个子模块隐式的从父模块中继续了这两个元素，消除了一些不须要的配置，如果遇到子模块必要使用和父模块不一样的groupId和verison，那么可以在子模块中显示声明
  

可继续的POM元素

• groupId：项目组ID，项目坐标的核心元素
  
• version：项目版本，项目坐标的核心元素
  
• description：项目的形貌信息
  
• organization：项目的构造信息
  
• inceptionYear：项目的创始年份
  
• url：项目的URL地点
  
• developers：项目的开发者信息
  
• contributors：项目的贡献者信息
  
• distributionManagement：项目的部署配置
  
• issueManagement：项目的缺陷跟踪系统信息
  
• ciManagement：项目的连续集成系统信息
  
• scm：项目的版本控制系统信息
  
• mailingLists：项目的邮件列表信息
  
• properties：自定义的Maven属性
  
• dependencies：项目的依赖配置
  
• dependencyManagement：项目的依赖管理配置
  
• repositories：项目的仓库配置
  
• build：包括项目的源码目次配置、输出目次配置、插件配置、插件管理配置等
  
• reporting：包括项目的陈诉输出目次配置、陈诉插件配置等。
  

依赖管理

1.     <dependencies>
2.         <dependency>
3.             <groupId>org.springframework.boot</groupId>
4.             <artifactId>spring-boot-starter-web</artifactId>
5.             <version>2.3.2.RELEASE</version>
6.         </dependency>
7.         <dependency>
8.             <groupId>org.springframework.boot</groupId>
9.             <artifactId>spring-boot-starter-test</artifactId>
10.             <version>2.3.2.RELEASE</version>
11.         </dependency>
12.         <dependency>
13.             <groupId>cn.hutool</groupId>
14.             <artifactId>hutool-all</artifactId>
15.             <version>5.8.12</version>
16.         </dependency>
17.         <dependency>
18.             <groupId>org.projectlombok</groupId>
19.             <artifactId>lombok</artifactId>
20.             <optional>true</optional>
21.         </dependency>
22.         <dependency>
23.             <groupId>com.zaxxer</groupId>
24.             <artifactId>HikariCP</artifactId>
25.         </dependency>
26.     </dependencies>

复制代码

maven的可继续元素列表包含了dependencies元素，这说明依赖是会被继续的，这时我们可以将一些共用依赖放到父模块中，子模块就可以移除这些依赖，简化配置。但同时也会产生其他标题，目前我们的子模块中都必要上述父模块中的依赖，如果将来项目中必要参加一个util模块，该模块只是必要提供一些工具，与springframework完全无关，岂非也让它依赖sping相关依赖吗？这样显然是不合理的。为此 Maven 引入了 dependencyManagement 来对依赖进行管理。
dependencyManagement

1.     <!-- 该标签只用来控制版本，不能将依赖引入 -->
2.     <dependencyManagement>
3.         <dependencies>
4.             <dependency>
5.                 <groupId>org.springframework.boot</groupId>
6.                 <artifactId>spring-boot-starter-web</artifactId>
7.                 <version>2.3.2.RELEASE</version>
8.             </dependency>
9.             <dependency>
10.                 <groupId>org.springframework.boot</groupId>
11.                 <artifactId>spring-boot-starter-test</artifactId>
12.                 <version>2.3.2.RELEASE</version>
13.             </dependency>
14.         </dependencies>
15.     </dependencyManagement>

复制代码

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

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

更改pipeline 子模块对应的配置，我们在dependencies中只必要配置 groupId 和 artifactId，省去了 version 和 scope。之所以可以或许省略这些信息，是因为它们继续了父模块 Root 中 dependencyManagement 的配置，其完备的依赖声明已经包含在父模块的 POM 中，子模块只必要配置 groupId 和 artifactId 就能得到相应的依赖信息，从而引入精确的依赖。
优点：

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

扩展

1.     <parent>
2.         <groupId>org.springframework.boot</groupId>
3.         <artifactId>spring-boot-starter-parent</artifactId>
4.         <version>2.3.2.RELEASE</version>
5.     </parent>

复制代码

单继续标题

现在有个标题，我现在想使用spring-boot-starter-parent提供的依赖管理，但是我又不想继续他，因为我还要继续别的项目，这时候该怎么办呢？
   maven和Java一样都是单继续机制，maven当中有pom和import ，通过这两个标签在dependencyManagement中声明依赖，可以更换继续（达到类似parent标签的作用，解决了单继续标题）。
  官网解说：https://docs.spring.io/spring-boot/maven-plugin/using.html

1. <dependencyManagement>
2.          <dependencies>
3.                 <dependency>
4.                          <groupId>org.springframework.boot</groupId>
5.                          <artifactId>spring-boot-dependencies</artifactId>
6.                          <version>2.3.2.RELEASE</version>
7.                          <type>pom</type>
8.                          <scope>import</scope>
9.                  </dependency>
10.         </dependencies>
11. </dependencyManagement>
13. 类似于
15. <parent>
16.     <groupId>org.springframework.boot</groupId>
17.     <artifactId>spring-boot-starter-parent</artifactId>
18.     <version>2.3.2.RELEASE</version>
19.     <relativePath/>
20. </parent>

复制代码

注意：使用dependencyManagement来更换parent的时候，pluginManagement内里嵌套的plugins版本并没有继续过来。
总结

保举自定义dependencies，不使用spring-boot-dependencies，版本控制更加灵活，spring-boot-dependencies中不存在的依赖也可以添加进去，版本依赖进行升级时，自主控制，不会出现多个子模块使用同一依赖项版本不一致的情况，降低依赖冲突的几率。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。