一文带你搞懂Maven的版本管理

前言

之前我在一文带你快速入门Maven中分享过可以使用properties标签抽取某个系列框架的版本号，这样做的好处是可以统一管理某个系列框架的版本号，方便后期的版本升级维护。后面我又在一文带你掌握Maven的父子工程中分享了可以通过父项目中的dependencyManagement标签来提取所有子模块的版本号，这样做的好处是每个子模块在引入依赖时不需要关心依赖的版本号，还有就是将来如果某个依赖的版本需要升级，只需要在父模块中修改该依赖的版本号即可，不需要去一个个的找到所有用到这个依赖的子模块，然后在各个子模块中修改版本号。

上面这两种技巧已经覆盖了绝大部分依赖版本管理的场景，还有一种场景没有覆盖到，那就是如果我们有多个类似于淘宝那样的多模块项目，那么每个项目中的父模块的pom.xml中都会有一对dependencyManagement标签包围起来的大片配置来统一管理所有子模块中依赖的版本号，就像下面这样：

  <properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <hutool.version>5.8.20</hutool.version>
    <kafka.version>3.7.0</kafka.version>
    <kaptcha.version>2.3.3</kaptcha.version>
    <fastjson.version>2.0.20</fastjson.version>
    <oshi.version>6.4.0</oshi.version>
    <commons.io.version>2.11.0</commons.io.version>
    <commons.fileupload.version>1.4</commons.fileupload.version>
    <commons.collections.version>3.2.2</commons.collections.version>
    <poi.version>4.1.2</poi.version>
    <jwt.version>0.9.1</jwt.version>
  </properties>

  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>cn.hutool</groupId>
        <artifactId>hutool-all</artifactId>
        <version>${hutool.version}</version>
      </dependency>
      
      <dependency>
        <groupId>org.apache.kafka</groupId>
        <artifactId>kafka-clients</artifactId>
        <version>${kafka.version}</version>
      </dependency>

      <dependency>
        <groupId>commons-io</groupId>
        <artifactId>commons-io</artifactId>
        <version>${commons.io.version}</version>
      </dependency>

      <!-- 文件上传工具类 -->
      <dependency>
        <groupId>commons-fileupload</groupId>
        <artifactId>commons-fileupload</artifactId>
        <version>${commons.fileupload.version}</version>
      </dependency>

      <!-- excel工具 -->
      <dependency>
        <groupId>org.apache.poi</groupId>
        <artifactId>poi-ooxml</artifactId>
        <version>${poi.version}</version>
      </dependency>

      <!-- collections工具类 -->
      <dependency>
        <groupId>commons-collections</groupId>
        <artifactId>commons-collections</artifactId>
        <version>${commons.collections.version}</version>
      </dependency>

      <!-- 阿里JSON解析器 -->
      <dependency>
        <groupId>com.alibaba.fastjson2</groupId>
        <artifactId>fastjson2</artifactId>
        <version>${fastjson.version}</version>
      </dependency>

      <!-- Token生成与解析-->
      <dependency>
        <groupId>io.jsonwebtoken</groupId>
        <artifactId>jjwt</artifactId>
        <version>${jwt.version}</version>
      </dependency>

      <!-- 验证码 -->
      <dependency>
        <groupId>pro.fessional</groupId>
        <artifactId>kaptcha</artifactId>
        <version>${kaptcha.version}</version>
      </dependency>
    </dependencies>

  </dependencyManagement>

我们程序员天生就不喜欢重复的东西，凡是重复的东西我们总想提取出来统一管理，这样方便维护，比直接复制粘贴是更好的办法。

那么我们有没有什么办法，将上面的配置抽取出来，然后在所有项目中引用呢？这就是我们这篇文章的主题了。

具体做法就是将上面的版本管理配置放到一个新的项目中，打包成pom，然后其他父项目中引入项目的pom即可。如下图所示：


经过上图的操作后，我们已经将所有依赖版本的配置打成了一个pom包，然后我们再在其他项目中引入这个pom包中的版本配置，具体怎么引入有两种方式：

1. 将这个pom包工程作为一个父工程。这样当前工程就是它的子工程，而前面我们在一文带你掌握Maven的父子工程中提到过子工程可以继承父工程的pom配置。
2. 使用import导入上面的pom包。

这两种方式都很常用，下面我们分别讲讲这两种方式

使用父子工程导入版本配置

这里假设我们有一个订单项目需要使用前面打包好的pom配置，具体操作如下图所示：

首先我们使用parent标签将前面的pom包作为父工程引入，然后我们引入一个kafka-clients的依赖，并且不指定版本号，我们可以看到实际引入的kafka-clients的版本就是csdn-dependencies项目pom.xml中kafka-clients的版本号，这说明我们的方式是有效的。

使用import导入版本配置

这里假设我们有一个消息项目需要引入前面csdn-dependencies项目中的版本管理配置，具体引入方式如下图：

然后我们尝试添加一个依赖并且不指定版本试试：

这里我们引入了jjwt的依赖，并且没有指定版本号，最终我们可以发现实际引入的jjwt的版本就是csdn-dependencies项目中pom.xml中定义的jjwt的版本，这说明这种方式也是有效的。

文章中的代码地址

文章中示例代码的地址

最后的总结

这篇文章中我们讲到了如何抽取多个项目的dependenceMangement中的依赖版本配置，以后我们在多个项目中就不用写重复的dependenceMangement依赖版本配置了，而是直接引入公共的pom包，减少重复配置。这样做的好处是可以避免项目在引入依赖过程中发生依赖版本冲突的问题，可以降低所有项目管理依赖版本的难度。

相信阅读过这篇文章的朋友应该对如何使用Maven更好的管理项目中依赖的版本有了更深刻的认识，关于Maven的依赖版本管理，我还写过另外两篇文章，感兴趣的朋友可以看看：

1. 一文带你快速入门Maven
2. 一文带你掌握Maven的父子工程

觉得有收获的朋友可以为我点个赞，您的鼓励就是我最大的动力！