声明自己的父模块是谁,以及自己的 GAV 坐标,可能细心的你发现了这里他并没有写 GroupId 和 Version 这是因为父工程已经声明了,如果没有特别的版本号和 groupId 的要求直接继承父工程的内容。
▐ 依赖传递
Maven 支持通过父 POM 中的依赖继承的方式避免开我们手动指定依赖库的版本。但是传递依赖会导致依赖图迅速增长的特别大,所以 Maven 对于传递依赖有一定的限制:
-
当依赖了多个版本的组件时 Maven 只会选择其中一个版本作为依赖,而选择的策略称为:nearest definition 最短路径
-
依赖自动引入: 当 A 依赖了 B 而 C 依赖了 A 那么 C 组件会自动引入 B 组件
-
依赖排除:这个理解起来就很简单 ,如果不想引入自动引入的一些依赖可以通过,排除依赖的手段将其去掉
▐ 依赖范围
依赖项的范围决定了什么时候这些依赖会被加载进去,在 Jar 瘦身等操作的时候特别有用,同时解决依赖冲突也是一把好手
-
compile 这个是默认值,也就是没有写作用域的依赖项在编译和运行阶段都会被加载到类路径
-
provided 这个和 compile 非常类似只是他仅在编译和测试阶段被加载,运行时不会。例如我们常常使用的 Servlet API 这个 jar 仅仅是在编译测试需要,运行时 Tomcat 早已为我们准备好了这个 Jar ,如果加了反而会可能导致类冲突
-
runtime 此范围表示编译时不需要依赖项,但是执行时需要依赖项,例如数据库的驱动
-
test 这个基本都是一些跑单测会依赖的 Jar
-
system 从参与度来说,和 provided 相同,不过被依赖项不会从maven仓库抓,而是从本地文件系统拿,一定需要配合systemPath属性使用。
当前项目为 A,A依赖于B,B依赖于C。知道B在A项目中的scope,那么怎么知道C在A中的scope呢?这个就需要根据 nexus 的一张表来确定:
比如 A 依赖 B 的范围为 provided ,B 依赖 C 的范围为 runtime 的 最终 A 依赖 C 的范围为 provided
大坑
在回到我们一开始提出的问题,如果团队里三个人开发同一个应用,大家都需要修改二方包的版本号,分支合并一定会冲突。同时引用这个二方包的应用也一定会冲突,因为大家使用的版本号一般都不同,那么以谁的为准?谁来解决这个冲突?往往因为版本号的问题导致冲突合并半小时应用都不一定可以构建的起来。
同时在发布上线的时候要改包为正式包,需要替换很多个地方,大家的版本还需要一致,往往需要解决多个地方的版本冲突。
为了解决这个问题,我采用了如下的方案:
-
大家在同一个环境开发的时候版本号永远都保持统一,比如在预发你的包版本只能是 pre0-snapshot 否则分支提交不上去
-
所有的包版本都收束到主 POM 中,禁止单独在每个 POM 中单独声明要发布或依赖的二方包
改造前后,主 POM样子如下:
子 POM 中就不在单独声明版本号了 而是直接继承父 POM 中定义的版本号:
这样确实很好的解决了上面的两个问题,但是在某次部署过程中遇到了一个非常诡异的问题。
我们项目结构如下:
ProjA
| – Apache Commons 3.0
|________
| Proj B’s Client
| | – mq-client
| | – redis-client
| | – etc.
|
|________
Server
| – Server Libraries
| – etc.
A 工程引用了 B 工程的 client 包,而其 client 包中引入了 mq 和 redis 的客户端,因此 A 工程在不用引入这两个包的情况下可以直接使用这两个包中的类。但是在某次部署的过程中,A 工程怎么都找不到 mq 和 redis 的类文件,这就让人摸不着头脑了,线上都是可以的,为何预发就有这个问题了???
溯源
又到了紧张而又刺激的问题排查阶段了。从 mvn 仓库上下载了最新的编译后的包放到 jad 中发现代码都是和我的分支保持一致的,没有啥问题,而且看到 snapshot 包后面的时间戳也是我发布包的时间戳。
那也就是发包的过程和结果都没啥问题,肯定是拉包的时候出问题了呗,看看拉包的过程是否有异常。
mvn clean && mvn install -fn
一套命令跑下来,好像也没有 error,但是包就是拉不下来。看看日志里面有什么猫腻吧!一顿日志的搜查发现了一行 waring 日志:应用引入的依赖包无效,依赖包中传递依赖项不可用,可以通过开启debug获取更多信息。
[WARNING] the POM for A is invalid, transitive dependencies (if any) will not be available, enable debug logging for more details…
开启maven debug功能后,警告后紧跟了一条错误信息,如下。
[WARNING] The POM forxx:jar:1.0-SNAPSHOT is invalid, transitive dependencies (if any) will not be available: 2 problems were encountered while building the effective model for xx:1.0-SNAPSHOT
[ERROR] ‘dependencies.dependency.version’ for xx:jar is missing.
[ERROR] ‘dependencies.dependency.version’ for xx:jar is missing.
transitive dependencies 这玩意不就是依赖传递么,我已开始还不知道遇到的这个问题如何用文字向搜索引擎描述,现在显然就是传递依赖的一些包没有被引入啊,这不就找到问题所在了, 因为下面有两个包没有声明 jar 的包版本。
但是为何会出现这个问题呢?根据上述报错的关键字我在 stackoverflow 中找到了答案:
One reason for this is when you rely on a project for which the parent pom is outdated. This often happens if you are updating the parent pom without installing/deploying it.
To see if this is the case, just run with mvn dependency:tree -X
and search for the exact error. It will mention it misses things you know are in the parent pom, not in the artifact you depend on (e.g. a jar version).
The fix is pretty simple: install the parent pom using mvn install -N
and re-try
上面短短几句话即说明了原因也给出了解决方案,美利坚的程序员果然牛皮!描述的大致意思就是因为这个二方包的父 POM 用的是老版本里面没有包含一些传递依赖的 jar 包的版本导致很多包拉不下来。解决方案也很简单直接把父 POM 中的依赖版本号加上并重新打包发布下就好了。
回顾上面说的组件的传递依赖,这里的二方包中依赖的 redis 和 mq 的 client 包没有拉下来是因为二方包 POM 中的某个 jar 的版本号即没有在父 POM 中定义也没有在二方 POM 中定义。二方包在找组件的依赖的时候首先会在本 POM 找,如果没有找到就会根据
module-test
org.example
1.0-SNAPSHOT
声明的父 POM 的版本号去父 POM 中找,因为父 POM 用的老版本里面根本没有那个包的版本号所以就报了刚才那个错误。
所以如果要发布新的二方包而且想要使用传递依赖的特性的话一定要重新发布父 POM !!!
自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。
深知大多数Java工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则几千的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年Java开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Java开发知识点,真正体系化!
由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!
如果你觉得这些内容对你有帮助,可以扫码获取!!(备注Java获取)
总结
我们总是喜欢瞻仰大厂的大神们,但实际上大神也不过凡人,与菜鸟程序员相比,也就多花了几分心思,如果你再不努力,差距也只会越来越大。
面试题多多少少对于你接下来所要做的事肯定有点帮助,但我更希望你能透过面试题去总结自己的不足,以提高自己核心技术竞争力。每一次面试经历都是对你技术的扫盲,面试后的复盘总结效果是极好的!
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取!
际上大神也不过凡人,与菜鸟程序员相比,也就多花了几分心思,如果你再不努力,差距也只会越来越大。
面试题多多少少对于你接下来所要做的事肯定有点帮助,但我更希望你能透过面试题去总结自己的不足,以提高自己核心技术竞争力。每一次面试经历都是对你技术的扫盲,面试后的复盘总结效果是极好的!
[外链图片转存中…(img-plKQ1Qh9-1713560024197)]
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取!