你真的弄清楚SpringBoot的依赖管理了吗?

原创
2020/12/26 18:09
阅读数 3.4K

1. 简介

最近在处理一个SpringBoot多模块项目的时候遇到一个问题,一个pom中只能有一个parent。

使用SpringBoot把SpringBoot设置为parent之后,项目本身就不能做为父项目添加子模块module了。

怎么处理?使用dependencyManagement。

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

dependencyManagement为什么有效?

在SpringBoot中我们经常使用依赖不带版本为什么也可以?

2. dependencyManagement

dependencyManagement其实主要不是为了解决继承问题,而是为了解决依赖版本混乱问题。

dependencyManagement主要用于多模块项目的父项目中。

它的原理是:

当maven发现dependencies中的某个dependency没有设置版本号version,它就会从它的父项目开始,在它的祖先项目中查找dependencyManagement中配置的dependency,直到找到一个有版本号version的依赖,使用该version。

从名字也可以看出dependencyManagement不是为了定义依赖,而是为了管理可能的依赖。有点绕,说个结论,就是如果在子模块中没有使用dependencyManagement定义的依赖,这些依赖的jar包就最终不会被打在输出的jar包中。

3. 为什么使用SpringBoot很多依赖可以不用配置版本号

如果你看SpringBoot的pom就会发现它的父项目是:

<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-dependencies</artifactId>

spring-boot-dependencies中基本啥都没干,就定义了默认的依赖和版本了。

spring-boot-dependencies的pom大致就像下面这个样子的:

SpringBoot依赖管理

有兴趣的朋友可以看一下这个pom中定义了哪些依赖,及其使用的版本。

4. 依赖管理

像SpringBoot一样,我们在多模块项目中也可以这样玩,首先找出多个模块的共同依赖,然后把他上移到父模块的dependencyManagement,像这样:

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

        <dependency>
            <groupId>com.google.guava</groupId>
            <artifactId>guava</artifactId>
            <version>${guava.version}</version>
        </dependency>
    </dependencies>
</dependencyManagement>

依赖上移之后,子模块的pom中要移除这些依赖,否则会覆盖定义在父项目中的dependencyManagement中的依赖。

dependencyManagement中的dependencies下的依赖不能直接被子模块继承,必须显式申明。直接在dependencies下的依赖可以被子项目继承。

# 分析哪些依赖使用了但是没有显式定义,哪些依赖定义了没有使用
mvn dependency:analyze

# 分析依赖层级关系
mvn dependency:tree

# 查看有效依赖
mvn help:effective-pom

5. scope

5.1 compile

默认的依赖范围就是compile,没有scope或者scope为comile的依赖表示编译、运行、测试的时候都需要这个依赖的jar包。

5.2 provided

表示环境已经提供了,所以打包的时候就不会将scope为provided的依赖打到输出的jar包中。

最典型的例子是servlet-api,因为这个依赖已经包含在像Tomcat这样的Servlet服务器中了,所以打包的时候就不需要将这个依赖再打包到输出jar包中了。

<dependency>
    <groupId>javax.servlet</groupId>
    <artifactId>servlet-api</artifactId>
    <version>3.0.1</version>
    <scope>provided</scope>
</dependency>

5.3 runtime

如果一个依赖的scope为runtime,表示编译的时候不能引用这个依赖的jar包。

还有编译的时候不需要运行的时候需要的jar包?

SPI相关的都是。主要是让面向接口变成,而不要直接去使用实现类,如使用java.sql.Driver,而不是com.mysql.cj.jdbc.Driver。

<dependency>
    <groupId>mysql</groupId>
    <artifactId>mysql-connector-java</artifactId>
    <version>${mysql.version}</version>
    <scope>runtime</scope>
</dependency>

5.4 test

scope为test的依赖表示,这个包只是在测试阶段使用,打包的时候这些依赖不会打在输出的jar包中。

<dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>${junit.version}</version>
    <scope>test</scope>
</dependency>

5.5 system

system主要是为了引入一些没有通过maven发布的私有的三方jar包。

这些jar包的特点是:

  1. 没有发布,所以不能通过maven中央仓库找到
  2. 是第三方的,所以不能使用自己的私服引入
  3. 只有jar包

当然你可以把这些jar包加在classpath中,但是对于maven项目来说不好管理。

这个时候,就可以使用scope为system的依赖了,只需要指定这些jar包在系统中的路径就可以了。

<dependency>
    <groupId>vip.mycollege</groupId>
    <artifactId>tools</artifactId>
    <version>1.0.0</version>
    <scope>system</scope>
    <systemPath>F:/lib/tools.jar</systemPath>
</dependency>

5.6 import

import只能在dependencyManagement的dependency,并且type为pom的依赖中使用。

import主要是为了将依赖管理和依赖定义分开。

例如SpringBoot的dependencyManagement中预定义很多依赖,所以就单独弄了一个spring-boot-dependencies来管理这些依赖。

6. optional

optional是用于控制依赖传递的。

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-devtools</artifactId>
    <optional>true</optional>
</dependency>

optional设置为true,这个依赖不会被传递,加入在A项目中添加了这个依赖,B项目依赖A,但是B项目不会依赖spring-boot-devtools。

展开阅读全文
打赏
1
4 收藏
分享
加载中
打赏
0 评论
4 收藏
1
分享
返回顶部
顶部