网站首页 > 博客文章 正文
现在Maven项目管理,在开发中时比较常用的,在一些项目汇总遇到依赖冲突的问题之后,还是没有能有一个很好的解决办法,这次就来看看在使用Maven管理依赖的过程中dependencies与dependencyManagement的区别,
DepencyManagement应用场景
当我们的项目模块很多的时候,使用Maven管理项目是非常方便的,它可以我们管理、构建、文档、报告、依赖、SCMS、发布、分发等等一系列的东西。可以方便编译代码、进行依赖管理、管理二进制库等等操作。
由于在项目中使用的模块较多,所以又可以抽象一层,抽出一个itoo-base-parent来管理子项目的公共依赖。为了项目能够正确地运行,必须让所有子项目使用依赖项的统一版本,必须确保应用的各个项目的依赖项和版本一致,才能保证测试和发布是相同的结果。
在项目的顶层的POM文件中,会看到一个dependencyManagement元素。通过它来管理jar的版本,让子项目中引用一个依赖而不用显示的列出版本号。Maven会沿着父层次向上走,直到找到拥有dependencyManagement元素的项目,然后她就会使用在这个dependencyManagement元素中指定的版本号。
<dependencyManagement>
<dependencies>
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<version>${javaee-api.version}</version>
</dependency>
</dependencies>
</dependencyManagement>
<!--继承父类-->
<parent>
<artifactId>itoo-base-parent</artifactId>
<groupId>com.tgb</groupId>
<version>0.0.1-SNAPSHOT</version>
<relativePath>../itoo-base-parent/pom.xml</relativePath>
</parent>
<modelVersion>4.0.0</modelVersion>
<artifactId>itoo-base</artifactId>
<packaging>ejb</packaging>
<!--依赖关系-->
<dependencies>
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-annotations</artifactId>
</dependency>
<dependency>
<groupId>org.eclipse.persistence</groupId>
<artifactId>org.eclipse.persistence.jpa</artifactId>
<scope>provided</scope>
</dependency>
</dependencies>
</project>
上面为了演示,拷贝的是网上资源,感谢资源主。
这样做的好处是:统一管理项目的版本号,确保应用的各个项目的依赖和版本一致,才能保证测试和发布是相同的成果。所以,在顶层pom中定义共同的依赖关系。同时可以避免在每个使用的子项目中都声明一个版本号,这样想升级或者想切换到另一个版本的时候只需要在父类容器中进行更新,而不需要任何一个子项目的修改;如果某个子项目需要另一个版本号的时候,只需要在dependencies中声明对应的版本号就可以了,子类就会使用子类声明的版本号,而不继承父类版本号。
Dependencies
dependencyManagement,所有生命在dependencies里的依赖都会自动引入,并默认被所有的子项目继承。
区别
dependencies 就是在子项目中不引入该依赖项,那么子项目中仍然会从父项目中继承该项目,这个继承属于是全部继承。
dependencyManagement 里只声明依赖,并不现实引入,因此子项目需要显示声明需要用的依赖。如果不在子项目中声明依赖,是不会从父项目中继承下来;只有在子项目中写入了该依赖项,并且没有指定具体的版本,才会从父项目再继承该依赖项,并且version和scope都是从父POM文件中进行读取。另外如果子项目中指定了版本号,那么会使用子项目中指定的版本号。
Maven 约定优于配置
Maven提出这样的约束主要是为项目提供合理的默认行为,不需要一些不必要的配置,提供了默认的目录
- src 源代码和测试代码的根目录
- main应用代码的目录
- java 源代码的目录
- resource 项目资源文件
- test 测试代码源目录
- target 编译后的各种文件、jar文件等的路径。
对于Maven的约定优于配置的理解,一方面对小型项目基本满足不需要自己配置东西,使用Maven已经配置好的东西,快速开发。另一方面,对于不满足的项目还需要一些自定义的内容,体现了灵活性。配置大量减少,随着项目的越复杂这种优势越明显。
总结区别
<dependencies>中jar直接加入到项目中,管理的是依赖关系(如果有父级pom,子级pom,则子级pom中只能被动接受父级的版本);
<dependencyManagement> 主要管理版本,对于子类继承同一个父类是很有用的,集中管理依赖版本不添加依赖关系,对于其中定义的版本,子pom中不一定继承父级pom中的所有版本。
猜你喜欢
- 2025-01-16 jackson学习之九:springboot整合(配置文件)
- 2025-01-16 流水号设计及Leaf的升级使用
- 2025-01-16 精通Spring Boot 3 : 10. 使用 Spring Boot 进行消息通信 (3)
- 2025-01-16 Java开发学习——SpringMVC之Rest风格解析及快速开发
- 2025-01-16 看了本文你再说不会Redis集群搭建配置,不会Spring 集成Redis看看
- 2025-01-16 话说关于 ZooKeeper 方面,面试有什么可问的啊?
- 2025-01-16 Elasticsearch 保姆级入门篇
- 2025-01-16 Maven最佳实践,程序员必知必会
- 2025-01-16 SpringBoot 默认json解析器详解和字段序列化自定义
- 2025-01-16 怎样在JAVA中解析JSON
你 发表评论:
欢迎- 367℃用AI Agent治理微服务的复杂性问题|QCon
- 360℃手把手教程「JavaWeb」优雅的SpringMvc+Mybatis整合之路
- 358℃初次使用IntelliJ IDEA新建Maven项目
- 351℃Maven技术方案最全手册(mavena)
- 348℃安利Touch Bar 专属应用,让闲置的Touch Bar活跃起来!
- 346℃InfoQ 2024 年趋势报告:架构篇(infoq+2024+年趋势报告:架构篇分析)
- 345℃IntelliJ IDEA 2018版本和2022版本创建 Maven 项目对比
- 342℃从头搭建 IntelliJ IDEA 环境(intellij idea建包)
- 最近发表
- 标签列表
-
- powershellfor (55)
- messagesource (56)
- aspose.pdf破解版 (56)
- promise.race (63)
- 2019cad序列号和密钥激活码 (62)
- window.performance (66)
- qt删除文件夹 (72)
- mysqlcaching_sha2_password (64)
- ubuntu升级gcc (58)
- nacos启动失败 (64)
- ssh-add (70)
- jwt漏洞 (58)
- macos14下载 (58)
- yarnnode (62)
- abstractqueuedsynchronizer (64)
- source~/.bashrc没有那个文件或目录 (65)
- springboot整合activiti工作流 (70)
- jmeter插件下载 (61)
- 抓包分析 (60)
- idea创建mavenweb项目 (65)
- vue回到顶部 (57)
- qcombobox样式表 (68)
- vue数组concat (56)
- tomcatundertow (58)
- pastemac (61)
本文暂时没有评论,来添加一个吧(●'◡'●)