Maven 依赖管理

最新推荐文章于 2023-01-01 22:54:51 发布
最新推荐文章于 2023-01-01 22:54:51 发布
阅读量640 收藏 1
点赞数 2
分类专栏： maven 文章标签： maven junit jar
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/program_red/article/details/77233854
版权

引入依赖

在maven引入jar依赖是通过:
<dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.10</version>
    </dependency>
 </dependencies>

* 详情可参考：
  https://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html

依赖范围

  • 什么是依赖范围
    在依赖包时，这些依赖的包怎么引入，引入之后作用在什么时候。这些就是依赖范围需要明确的，换句话说就是作用域。作用域范围就是classpath，maven将其划分成: 编译classpath, 测试classpath, 运行时classpath。根据定义的依赖范围来确认jar依赖最终引入到哪个classpath。
  • 有哪些依赖范围
scope编译classpath测试classpath运行classpath
compileYYY
testNYN
providedYYY
runtimeNYY
systemYYN
默认scope＝compile，相应引入的jar包，会加入到这三个classpath中；
* test：表示该jar包只是执行单元测试时使用，因此只需要引入到测试classpath即可；例如：junit包
* provided: 表示已经提供了，啥意思呢，意思就是在你运行的时候，这个已经提供好了，不需要你引入，只是在你编译或者测试时，需要引入。典型的就是servlet-api，为了正常编译和测试，我们通常会引入该包，但是在运行时，由于tomcat等容器已经提供了，并将相应的servlet-api包加载到了WEB-INF/lib。因此其只作用在编译classpath、测试classpath;
* runtime: 表示运行时引入，最直接会引入到运行时classpath, 不过这里也会引入到测试classpath，个人理解是因为在测试时，实际上会执行相应的代码逻辑，如果这段代码逻辑实际使用到了这个包，那么务必是需要引用的，因此也会作用在测试classpath，但是编译并不执行，只要接口ok，就不需要引入具体的实现包，典型：引入jdbc驱动，在编译时，并没有使用到具体的驱动实现包，但是在测试、运行时，需要使用；
* system: 这个的作用和provided基本一致，唯一的差别其引用不是通过maven进行解析的，而是通过设置systemPath 文件路径来引入的。
如何选择scope，关键在于期望哪个阶段（编译、测试、运行）使用包，然后再根据scope对应作用的classpath，从而确认scope的类型。

传递性依赖

  • 什么是传递性依赖
所谓的传递性依赖，就是: A -> B -> C (其中，A依赖B，B依赖C)，需要确认的是A->C之间的依赖情况。
依赖传递，可以减少依赖包的申明，简化依赖配置；但是也带来了新一些新问题。
  • 依赖传递方式
引入依赖时，需要确认依赖范围（默认compile），例如：A->B(compile)，B->C(compile)，那么A->C的依赖范围是怎样的？这是急需定义和解决的问题。
A -> B \ B->Ccompiletestprovidedruntimesystem
compilecompile––runtime–
testtest––test–
providedprovided–providedprovidedprovided
runtimeruntime––runtime–
systemsystem–systemsystemsystem
案例：maven-hello(A) , maven-common(B) , junit(C)
  • A->B(compile) + B->C(compile) => A - C （compile）
**maven-hello(A)**
<dependencies>
    <dependency>
      <groupId>study.wzp.maven</groupId>
      <artifactId>maven-common</artifactId>
      <version>1.0-SNAPSHOT</version>
      <scope>compile</scope>
    </dependency>
</dependencies>
**maven-hello(B)**
<dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.10</version>
            <scope>compile</scope>
        </dependency>
</dependencies>

这里写图片描述

现象：maven-hello 依赖 maven-common 范围是 compile, maven-common 依赖 junit 范围是 compile, 发现 maven-hello 依赖 junit 范围 compile;
  • A->B(compile) + B->C(test) => A - C （no relation）
**maven-hello(A)**
<dependencies>
    <dependency>
      <groupId>study.wzp.maven</groupId>
      <artifactId>maven-common</artifactId>
      <version>1.0-SNAPSHOT</version>
      <scope>compile</scope>
    </dependency>
</dependencies>
**maven-hello(B)**
<dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.10</version>
            <scope>test</scope>
        </dependency>
</dependencies>

这里写图片描述

现象：maven-hello 依赖 maven-common 范围是 compile, maven-common 依赖 junit 范围是 test, 发现 maven-hello 与 junit 无任何关系;
  • A->B(compile) + B->C(provided) => A - C （no relation）
**maven-hello(A)**
<dependencies>
    <dependency>
      <groupId>study.wzp.maven</groupId>
      <artifactId>maven-common</artifactId>
      <version>1.0-SNAPSHOT</version>
      <scope>compile</scope>
    </dependency>
</dependencies>
**maven-hello(B)**
<dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.10</version>
            <scope>provided</scope>
        </dependency>
</dependencies>

这里写图片描述

现象：maven-hello 依赖 maven-common 范围是 compile, maven-common 依赖 junit 范围是 provided, 发现 maven-hello 与 junit 无任何关系;
  • A->B(compile) + B->C(runtime) => A -> C （runtime）
**maven-hello(A)**
<dependencies>
    <dependency>
      <groupId>study.wzp.maven</groupId>
      <artifactId>maven-common</artifactId>
      <version>1.0-SNAPSHOT</version>
      <scope>compile</scope>
    </dependency>
</dependencies>
**maven-hello(B)**
<dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.10</version>
            <scope>runtime</scope>
        </dependency>
</dependencies>

这里写图片描述
这里写图片描述
这里写图片描述

现象：maven-hello 依赖 maven-common 范围是 compile, maven-common 依赖 junit 范围是 provided, 发现 maven-hello 依赖 junit 范围为 runtime ( 执行 mvn compile, mvn test 都会报错，但是执行mvn surefire:test 不会错，因为mvn test 执行了compile，找不到org.junit前提是代码中使用到了，这是因为包没有引入);
类似上述操作，其他情况可以逐一尝试，这里不做所有举例。 思路大概就是：
依赖关系的依赖范围，决定了这些包该引入到哪个classpath，如果A->B，根据scope确认了B将被引入到A的哪个classpath，然后再推进B->C，如果A存在直接使用C的情况，那么就会出现直接依赖，如果没有那么A与C之间可以认为是没有关系。
  • 依赖带来的问题
上面介绍的单个路径依赖，多出现多个路径依赖时，该如何进行依赖选择呢？

case1:

A -> B ->C -> X(1.0) && A -> D -> X(2.0)，maven采用最短路径方式选择；
1、A -> B ->C -> X(1.0) ，路径是3 
2、A -> D -> X(2.0)，路径是2；
那么选择路径为2的X(2.0)，这里不具体通过实例展示，有兴趣的可以，实现下。

case2:

如果路径相同时，那该如何选择呢？
A ->B -> X(1.0) && A -> C -> X(2.0)，maven采取谁先申明谁优先的原则；
假设，B先申明，那么会选择X(1.0)，反之X(2.0)；
举例：
1、maven-hello -> maven-common -> junit(4.10)
2、maven-hello -> maven-base -> junit(4.12)

maven-hello

<dependencies>

    <dependency>
      <groupId>study.wzp.maven</groupId>
      <artifactId>maven-base</artifactId>
      <version>1.0-SNAPSHOT</version>
      <scope>compile</scope>
    </dependency>

    <dependency>
      <groupId>study.wzp.maven</groupId>
      <artifactId>maven-common</artifactId>
      <version>1.0-SNAPSHOT</version>
      <scope>compile</scope>
    </dependency>

  </dependencies>

maven-common 

 <dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.10</version>
            <scope>compile</scope>
        </dependency>
</dependencies>

maven-base

<dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.12</version>
        </dependency>
</dependencies>
现象：maven-hello 依赖 junit(4.12) ，如果把pom.xml的依赖顺序，将maven-common提前，那么依赖的是junit;

这里写图片描述

先进行路径依赖长度判断，如果长度一样再使用优先配置选择（这种方式，支持maven2.0.9之后的版本）

依赖分析手段

    通常我们在构建项目，配置依赖时，难免出现过多依赖等不合理的依赖，可以通过一些命令来帮助查看依赖情况。
  • mvn dependency:list
列出依赖列表，例如：
[INFO] The following files have been resolved:
[INFO]    study.wzp.maven:maven-base:jar:1.0-SNAPSHOT:compile
[INFO]    org.hamcrest:hamcrest-core:jar:1.3:compile
[INFO]    study.wzp.maven:maven-common:jar:1.0-SNAPSHOT:compile
[INFO]    junit:junit:jar:4.12:compile
  • mvn dependency:tree
树形结构展示依赖列表：
[INFO] study.wzp.maven:maven-hello:pom:1.0-SNAPSHOT
[INFO] +- study.wzp.maven:maven-base:jar:1.0-SNAPSHOT:compile
[INFO] |  \- junit:junit:jar:4.12:compile
[INFO] |     \- org.hamcrest:hamcrest-core:jar:1.3:compile
[INFO] \- study.wzp.maven:maven-common:jar:1.0-SNAPSHOT:compile
  • mvn dependency:analyze
分析依赖情况，可以找出一些不合理的依赖。
INFO] --- maven-dependency-plugin:2.8:analyze (default-cli) @ maven-hello ---
[WARNING] Unused declared dependencies found:
[WARNING]    study.wzp.maven:maven-base:jar:1.0-SNAPSHOT:compile
[WARNING]    study.wzp.maven:maven-common:jar:1.0-SNAPSHOT:compile
[INFO] ------------------------------------------------------------------------
标识申明了junit，但是没有使用，类似这种提示处理。
依赖分析详情参考：https://maven.apache.org/components/plugins/maven-dependency-plugin/

参考

[1] https://maven.apache.org/components/plugins/maven-dependency-plugin/

紫守笨
关注
  • 2
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
Maven获取工程相关仓库的源码和javadoc方法
Bob Liu的程序人生
01-26 2449
背景 编写程序和研读代码时，离不开仓库的源码和javadoc，如何将相关文档添加到工程中非常重要。 获取方法 进入工程的根目录，运行下列命令： mvn dependency:sources -DdownloadSources=true -DdownloadJavadocs=true    Maven将开始下载源码与javadoc相关jar文件，下载完成后，会提示最终下载到的sou
maven依赖管理 继承管理
12-09
Maven就可以替我们自动的将当前jar包所依赖的其他所有jar包全部导入进来，无需人工参与，节约了我们大量的时间和精力。用实际例子来说明就是：通过Maven导入commons-fileupload-1.3.jar后，commons-io-2.0.1.jar会被...
【Maven】＜Maven解析＞依赖管理
范同学的学习历程
02-05 635
目录 一、依赖配置： 二、依赖传递： 依赖传递冲突问题： 三、可选依赖： 四、排除依赖： 五、依赖范围： 依赖范围传递性： 一、依赖配置： 依赖指的是当前项目运行所需要的jar，一个项目可以设置很多依赖： <!--设置当前项目运行所需的jar，一个项目可以设置多个依赖--> <dependencies> <!--设置具体的依赖--> <dependency> <!--依赖所属群组id--&g...
Maven 之 依赖管理
一切总会归于平淡
01-01 1214
我们开发一个工程需要用到大量得jar包，而这些jar 包就是我们所说得依赖，一个项目可以配置多个依赖。
Maven依赖管理
JustinNeil的博客
07-11 311
Maven项目，依赖，构建配置，以及构件：所有这些都是要建模和表述的对象。 这些对象通过一个名为项目对象模型(Project Object Model, POM)的XML文件描述。 这个POM告诉Maven它正处理什么类型的项目，如何修改默认的行为来从源码生成输出。 同样的方式，一个Java Web应用有一个web.xml文件来描述，配置，及自定义该应用，一个Maven项目则通过一个 pom.xm...
Maven-依赖管理
weixin_50369190的博客
11-30 253
Maven依赖管理（传递、可选、排除、冲突）以及依赖冲突三种情况会选择哪个版本的依赖。
Maven依赖管理项目构建工具.pdf
12-24
五、基于IDEA 进行Maven依赖管理 1. 依赖管理概念 Maven通过pom.xml文件管理项目的依赖，每个依赖都有其GAV信息，Maven会自动解决依赖的版本和传递性依赖。 2. Maven工程核心信息配置和解读（GAVP） pom.xml文件中...
Maven依赖管理项目构建工具（保姆级教学）
11-17
Maven的依赖管理遵循一些原则，如“最接近优先”规则，如果一个项目有两个或更多版本的相同依赖，Maven会优先选择离项目最近的依赖。此外，Maven还支持排除依赖，如果你不想引入某个特定的子依赖，可以通过...
Java开发之Maven依赖管理入门带阿里云源
06-13
适用人群：该教程适合软件开发人员、架构师以及对自动化构建和依赖管理感兴趣的IT专业人士。无论您是初学者还是有经验的Java开发者，都可以从中获益。 使用场景及目标：您可将此教程作为学习Maven的起点，理解其...
深入Maven依赖管理：精通依赖范围的艺术
最新发布
06-24
Maven的核心功能之一是依赖管理，它允许用户通过在`pom.xml`文件中声明依赖关系，自动处理项目所需的第三方库。 Maven工程的构建过程中，真正的jar包存放在仓库中，而项目中仅需放置jar包的坐标信息。这样，当需要...
maven 使用 狗剩学习笔记
狗剩的专栏
11-25 295
共6个小时 P1.maven的引言----------------------46:00 P2.maven的第一个环境搭建--------------------41:40 P3.maven与现有工具集成--------------------34:07 P4.maven中坐标依赖使用和maven中执行构建命令--------------------26:18 P5.maven中配置阿里云镜像--------------------40:45 P6.maven中创建web项目----------------
7. maven中的聚合与继承
lucyLee的博客
03-28 677
1. 絮絮叨叨 作为一名大数据开发工程师，经常需要对社区的大数据组件进行源码改造，以支持所在公司的特定需求。 大部分的大数据组件都是用Java开发的，一般都会选择使用maven进行项目的管理。 最近，自己有一个需求，需要在当前的maven项目中，新增一个单独的模块yyy-event。这是一个插件模块，用于实现特定的功能。 自己发现，新建的模块的pom文件有些特殊，因为在文件的开头，就有一个从未见过的<parent>标签。 <parent> <groupI
IDEA报错:The following problems have occurred when adding the files: The following paths are ignored
热门推荐
Michaeles的博客
12-04 1万+
在 Git Bash中输入git config core.longpaths true
Maven项目错误解决小结
weixin_34216196的博客
10-16 1049
Maven项目错误解决小结 注：整理错误，不喜欢为了一个小问题，占篇幅，所以请Ctrl+F自己查看，定位问题，愿为解决. 注：网络上的错误解决经验，只是作者在特定的条件下发生，或者适合你不适合你，请勿责怪，若无解决答案，请你请教他人或耐心解决，可以记录之后分享，我们爱分享，一起开始吧！ 问题1： -Dmaven.multiModuleProjectDi...
idea cannot download sources解决办法
qq_39360744的博客
03-25 356
参考：idea cannot download sources解决办法 Terminal输入：mvn dependency:resolve -Dclassifier=sources

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值