立聪堂德州十三局店 发表于 2024-9-7 01:17:42

Maven聚合与继续

聚合

   当我们一次想要构建多个项目时,而不是到每一个模块的目次下分别实行mvn命令。这个时候就必要使用到maven的聚合特性
https://i-blog.csdnimg.cn/direct/380cf0e00f8640c3b963509dd110e9c4.png#pic_center


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

   当我们多个模块下存在很多雷同的配置时,比方它们都有雷同的groupId和version,有雷同的spring-core,slf4j,junit依赖,还有雷同的maven-compiler-plugin配置时。在mavne的世界中,也有类似的机制能让我们抽取出重复的配置,这就是pom的继续
https://i-blog.csdnimg.cn/direct/142ca175f0ff47028d82353ee2dc74d9.png#pic_center


[*] 上图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:包括项目的陈诉输出目次配置、陈诉插件配置等。
依赖管理

    <dependencies>
      <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
            <version>2.3.2.RELEASE</version>
      </dependency>
      <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <version>2.3.2.RELEASE</version>
      </dependency>
      <dependency>
            <groupId>cn.hutool</groupId>
            <artifactId>hutool-all</artifactId>
            <version>5.8.12</version>
      </dependency>
      <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <optional>true</optional>
      </dependency>
      <dependency>
            <groupId>com.zaxxer</groupId>
            <artifactId>HikariCP</artifactId>
      </dependency>
    </dependencies>
maven的可继续元素列表包含了dependencies元素,这说明依赖是会被继续的,这时我们可以将一些共用依赖放到父模块中,子模块就可以移除这些依赖,简化配置。但同时也会产生其他标题,目前我们的子模块中都必要上述父模块中的依赖,如果将来项目中必要参加一个util模块,该模块只是必要提供一些工具,与springframework完全无关,岂非也让它依赖sping相关依赖吗?这样显然是不合理的。为此 Maven 引入了 dependencyManagement 来对依赖进行管理。
dependencyManagement

    <!-- 该标签只用来控制版本,不能将依赖引入 -->
    <dependencyManagement>
      <dependencies>
            <dependency>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-starter-web</artifactId>
                <version>2.3.2.RELEASE</version>
            </dependency>
            <dependency>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-starter-test</artifactId>
                <version>2.3.2.RELEASE</version>
            </dependency>
      </dependencies>
    </dependencyManagement>
Maven 可以通过 dependencyManagement 元素对依赖进行管理,它具有以下 2 大特性:


[*]在该元素下声明的依赖不会实际引入到模块中,只有在 dependencies 元素下同样声明了该依赖,才会引入到模块中。
[*]该元素可以或许约束 dependencies 下依赖的使用,即 dependencies 声明的依赖若未指定版本,则使用 dependencyManagement 中指定的版本,否则将覆盖 dependencyManagement 中的版本。
https://i-blog.csdnimg.cn/direct/e8ca73aa3d864596b25cdb3b878ded70.png#pic_center
更改pipeline 子模块对应的配置,我们在dependencies中只必要配置 groupId 和 artifactId,省去了 version 和 scope。之所以可以或许省略这些信息,是因为它们继续了父模块 Root 中 dependencyManagement 的配置,其完备的依赖声明已经包含在父模块的 POM 中,子模块只必要配置 groupId 和 artifactId 就能得到相应的依赖信息,从而引入精确的依赖。
优点:



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

    <parent>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-parent</artifactId>
      <version>2.3.2.RELEASE</version>
    </parent>
https://i-blog.csdnimg.cn/direct/8db11ad1b92540e792fe89cf08a9d70e.png#pic_center
https://i-blog.csdnimg.cn/direct/82f7b7f6f3f54e39bbb4fd2a6cb1b693.png#pic_center
单继续标题

现在有个标题,我现在想使用spring-boot-starter-parent提供的依赖管理,但是我又不想继续他,因为我还要继续别的项目,这时候该怎么办呢?
   maven和Java一样都是单继续机制,maven当中有pom和import ,通过这两个标签在dependencyManagement中声明依赖,可以更换继续(达到类似parent标签的作用,解决了单继续标题)。
官网解说:https://docs.spring.io/spring-boot/maven-plugin/using.html
https://i-blog.csdnimg.cn/direct/c30d1872655a48568668e221bc9d5c2a.png#pic_center
<dependencyManagement>
       <dependencies>
                <dependency>
                       <groupId>org.springframework.boot</groupId>
                       <artifactId>spring-boot-dependencies</artifactId>
                       <version>2.3.2.RELEASE</version>
                       <type>pom</type>
                       <scope>import</scope>
               </dependency>
        </dependencies>
</dependencyManagement>

类似于

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>2.3.2.RELEASE</version>
    <relativePath/>
</parent>

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

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

免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。
页: [1]
查看完整版本: Maven聚合与继续