Maven【3】( 依赖的范围,传递性和依赖的排除)(命令行操作)

简介: Maven【3】( 依赖的范围,传递性和依赖的排除)(命令行操作)

【1】依赖的范围

结论

compile 和 test 对比:

compile 和 provided 对比:

验证

①验证 compile 范围对 main 目录有效

main目录下的类为HelloServlet,compile范围引入的依赖为:pro01-maven-java,pro01-maven-java中的类为:Calculator,我们只需验证main目录下的类为HelloServlet能否使用Calculator即可。只需要通过import将要测试的类引入当前类,引入后如果编译能通过,则说明可用,这个范围的依赖对当前类有效。

我们来编译一下。发现成功了,说明是没有问题的:

②验证test范围对main目录无效

test范围的依赖为junit

junit可以使用的注解为@Test,那还是跟上面一样的原理:

然后编译一下发现编译不能通过:

③验证test和provided范围不参与服务器部署

我们需要验证:通过compile范围依赖的jar包会放入war包,通过test和provided范围依赖的jar包不会放入war包。

然后我们打包一下看一下:

发现只有通过compile范围依赖的jar包会放入war包。

【2】依赖的传递性

结论:

在 A 依赖 B,B 依赖 C 的前提下,C 是否能够传递到 A,取决于 B 依赖 C 时使用的依赖范围。

B 依赖 C 时使用 compile 范围:可以传递

B 依赖 C 时使用 test 或 provided 范围:不能传递,所以需要这样的 jar 包时,就必须在需要的地方明确配置依赖才可以。

①compile 范围:可以传递

我们来测试一下:

测试方式:让 pro01-maven-java 工程依赖 spring-core

具体操作:编辑 pro01-maven-java 工程根目录下 pom.xml,加入这个依赖:

<dependency>
  <groupId>org.springframework</groupId>
  <artifactId>spring-core</artifactId>
  <version>4.0.0.RELEASE</version>
</dependency>

然后使用 mvn dependency:tree 命令查看效果:

我们再来看一下这个依赖的pom文件:

所有当B 依赖 C 时如果使用 compile 范围,那么依赖是可以传递的。

②test 或 provided 范围:不能传递

我们可以看到pro01-maven-java 依赖了 junit,但是在 pro02-maven-web 工程中查看依赖树的时候并没有看到 junit,所以test范围不能传递。

要验证 provided 范围不能传递,可以在 pro01-maven-java 工程中加入 servlet-api 的依赖:

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

然后再查看pro02-maven-web 工程的依赖树,发现还是跟原来一样,并没有servlet-api这个依赖。

【3】依赖的排除

依赖排除就是:当 A 依赖 B,B 依赖 C 而且 C 可以传递到 A 的时候,A 不想要 C,需要在 A 里面把 C 排除掉。

依赖的排除目的就是为了避免架包的冲突。(架包的版本可能不一样)

所以配置依赖的排除其实就是阻止某些 jar 包的传递。因为这样的 jar 包传递过来会和其他 jar 包冲突。

我们来举个例子:

我们在 pro02-maven-web 工程中配置对 commons-logging 的排除。

先来看一下配置前的依赖:

配置方式:

<dependency>
  <groupId>com.atxiaoyu.maven</groupId>
  <artifactId>pro01-maven-java</artifactId>
  <version>1.0-SNAPSHOT</version>
  <scope>compile</scope>
  <!-- 使用excludes标签配置依赖的排除  -->
  <exclusions>
    <!-- 在exclude标签中配置一个具体的排除 -->
    <exclusion>
      <!-- 指定要排除的依赖的坐标(不需要写version) -->
      <groupId>commons-logging</groupId>
      <artifactId>commons-logging</artifactId>
    </exclusion>
  </exclusions>
</dependency>

配置完成后再来查看一下依赖:

我们可以发现在 spring-core 下面就没有 commons-logging 了。

目录
相关文章
|
Java Maven 微服务
微服务——SpringBoot使用归纳——Spring Boot集成 Swagger2 展现在线接口文档——Swagger2 的 maven 依赖
在项目中使用Swagger2工具时,需导入Maven依赖。尽管官方最高版本为2.8.0,但其展示效果不够理想且稳定性欠佳。实际开发中常用2.2.2版本,因其稳定且界面友好。以下是围绕2.2.2版本的Maven依赖配置,包括`springfox-swagger2`和`springfox-swagger-ui`两个模块。
540 0
|
11月前
|
存储 Java Maven
Maven系统级别依赖:解决部署时Jar包缺失问题
以上就是关于Maven系统级别依赖解决部署时Jar包缺失问题的解答,希望对你有所帮助。在软件开发中,遇到问题并解决问题是常态,希望你能够善用这些工具,解决你遇到的问题。
715 28
|
缓存 Java Maven
【简单四步教你解决♥十分有效】Maven依赖报错、依赖或插件导入失败的万能解决办法
【简单四步教你解决♥十分有效】Maven依赖报错、依赖或插件导入失败的万能解决办法!在处理Maven项目问题时,首先检查Maven配置是否正确。接着通过“File--Invalidata Caches”清除IDEA缓存并重启。使用Maven命令`mvn dependency:purge-local-repository`和`mvn dependency:resolve`清除本地依赖缓存。最后,在Terminal中输入`mvn clean install`完成构建。
4349 1
【简单四步教你解决♥十分有效】Maven依赖报错、依赖或插件导入失败的万能解决办法
|
缓存 架构师 Java
Maven实战进阶(01)面试官:Maven怎么解决依赖冲突?| 有几种解决方式
本文介绍了Maven的核心功能和依赖管理技巧。Maven是基于项目对象模型(POM)的构建工具,具备跨平台、标准化、自动化等特性。其三大核心功能为依赖管理、仓库管理和项目构建。依赖管理通过pom.xml文件引入第三方组件并自动下载;仓库管理涉及中央仓库、私服和本地仓库;项目构建则通过生命周期管理编译、测试、打包等流程。文章还详细讲解了依赖冲突的解决方法,包括默认规则、手工排除和版本指定等策略。
|
Java Maven
maven打瘦包,且只打入部分想打入的依赖瘦包
maven打瘦包,且只打入部分想打入的依赖瘦包 设计 工程结构分析 环境管理 城市资源 安全工程 工程管理
334 10
|
XML 安全 Java
【Maven】依赖管理,Maven仓库,Maven核心功能
【Maven】依赖管理,Maven仓库,Maven核心功能
2222 3
|
8月前
|
Java 区块链 Maven
关于引入maven项目后出现‘parent.relativePath’ of POM错误时的解决方法
关于引入maven项目后出现‘parent.relativePath’ of POM错误时的解决方法
661 3
|
7月前
|
Java jenkins 应用服务中间件
结合Jenkins与Tomcat,实施Maven项目的自动构建和部署流程。
任何项目构建和部署的自动化流程,总离不开对各个环节精细把控与密切配合。涉及到源代码管理、构建工具、持续集成服务器以及最终的运行时环境的协调。通过上述简洁实用的步骤,可以实现Maven项目从源代码到运行状态的无缝过渡,进而提升软件开发的效率与质量。
404 0
|
Java Maven 开发者
maven项目中官方setting.xml文件
`settings.xml` 是 Maven 的配置文件,用于定义用户或全局级别的构建行为。它包含本地仓库路径、网络代理、服务器认证、仓库镜像及构建配置文件等设置,帮助开发者根据环境定制 Maven 行为,提升构建效率与灵活性。
1471 0