maven笔记的后续补充

最新推荐文章于 2024-10-18 17:48:19 发布

君と僕903

最新推荐文章于 2024-10-18 17:48:19 发布

阅读量1.1k

点赞数 22

文章标签： maven 笔记

本文链接：https://blog.csdn.net/weixin_59335007/article/details/141260575

版权

Maven 工程 Build 构建配置

项目构建是指将源代码、依赖库和资源文件等转换成可执行或可部署的应用程序的过程，在这个过程中包括编译源

代码、链接依赖库、打包和部署等多个步骤。

默认情况下，构建不需要额外配置，都有对应的缺省配置。当然了，我们也可以在 pom.xml 定制一些配置，来修

改默认构建的行为和产物！

例如：

指定构建打包文件的名称，非默认名称
指定构建打包时，包含文件格式和排除文件
打包插件版本过低，配置更高版本插件

构建配置是在 pom.xml / build 标签中指定！

Maven 依赖传递和依赖冲突

Maven 依赖传递特性

概念

假如有 Maven 项目 A，项目 B 依赖 A，项目 C 依赖 B。那么我们可以说 C 依赖 A。也就是说，依赖的关系为：C

—>B—>A，那么我们执行项目 C 时，会自动把 B、A 都下载导入到 C 项目的 jar 包文件夹中，这就是依赖的传递

性。

作用

简化依赖导入过程
确保依赖版本正确

传递的原则

在 C 依赖 B，B 依赖 A 的前提下，A 是否能够传递到 C，取决于 B 依赖 A 时使用的依赖范围以及配置

B 依赖 A 时使用 compile 范围：可以传递
B 依赖 A 时使用 test 或 provided 范围：不能传递，所以需要这样的 jar 包时，就必须在需要的地方明确配置依赖才可以
B 依赖 A 时，若配置了以下标签，则不能传递

依赖传递终止的情况

非 compile 范围进行依赖传递
使用 optional 配置终止传递
依赖冲突（传递的依赖已经存在）

Maven 依赖冲突特性

当直接引用或者间接引用出现了相同的 jar 包! 这时呢，一个项目就会出现相同的重复 jar 包，这就算作冲突！依赖

冲突会终止依赖传递！

![外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传](https://img-home.csdnimg.cn/images/20230724024159.png?origin_url=D%3A%5CLearn%5Cxinsizhixue%5Cnote%5Cmaven.assets%5Cimage-20240812172038681.png&pos_id=img-QEbkij3W-1723792393150

maven 自动解决依赖冲突问题能力，会按照自己的原则，进行重复依赖选择。同时也提供了手动解决的冲突的方式。

解决依赖冲突（如何选择重复依赖）方式：

自动选择原则

短路优先原则（第一原则）

A—>B—>C—>D—>E—>X(version 0.0.1)

A—>F—>X(version 0.0.2)

则 A 依赖于X(version 0.0.2)。

依赖路径长度相同情况下，则“先声明优先”（第二原则）

A—>E—>X(version 0.0.1)

A—>F—>X(version 0.0.2)

在中，先声明的，路径相同，会优先选择！

Maven 工程继承和聚合关系

Maven 工程继承关系

继承概念

Maven 继承是指在 Maven 的项目中，让一个项目从另一个项目中继承配置信息的机制。继承可以让我们在多个项目中共享同一配置信息，简化项目的管理和维护工作。

继承作用

在父工程中统一管理项目中的依赖信息。

它的背景是：

对一个比较大型的项目进行了模块拆分
一个 project 下面，创建了很多个 module
每一个 module 都需要配置自己的依赖信息

它背后的需求是：

在每一个 module 中各自维护各自的依赖信息很容易发生出入，不易统一管理
使用同一个框架内的不同 jar 包，它们应该是同一个版本，所以整个项目中使用的框架版本需要统一
使用框架时所需要的 jar 包组合（或者说依赖信息组合）需要经过长期摸索和反复调试，最终确定一个可用组合。这个耗费很大精力总结出来的方案不应该在新的项目中重新摸索。通过在父工程中为整个项目维护依赖信息的组合既保证了整个项目使用规范、准确的 jar 包；又能够将以往的经验沉淀下来，节约时间和精力