背景介绍

首先maven工程结构大致是这样 (注意maven仓库是本地仓库-公司中央仓库-远程仓库, 可能对理解遇到的问题原因和为何那样解决有些帮助):

	<groupId>com.xx.bigdata</groupId><artifactId>service-manager</artifactId><version>1.0</version><packaging>pom</packaging><modules><module>service-base</module><module>service-a</module><module>service-b</module></modules>

我们在父工程service-manager下面有一个公共包service-base,然后有两个子服务service-a和service-b
其中service-a和service-b是具体的业务服务; 两个服务有不少公共逻辑(比如邮件, 基础工具包等)是在service-base,正常情况下, 当我们在service-base中引入依赖, 利用<scope> 标签就可以将service-a和service同时需要的依赖jar包统一放到service-base下管理,从而避免到处重复依赖的问题(以上文字描述如果觉得抽象,可以看下面的例子)

用一个比较实用的场景案例,比如service-base和两个子服务都需要的lombok包
最终配置是这样的:

service-manager(父工程pom)

<properties><lombok.version>1.16.18</lombok.version><service.base.version>1.0.1</service.base.version>
</properties>
<dependency><groupId>org.projectlombok</groupId><artifactId>lombok</artifactId><version>${lombok.version}</version>
</dependency>

service-base(基础工具包)

<dependency><groupId>org.projectlombok</groupId><artifactId>lombok</artifactId>
</dependency>

service-a(子服务a,依赖了service-base后,由于service-base中依赖了lombok包,并且scope为compile[默认], 这里即可不再显式依赖lombok包)

<!--所有子服务工程均需要的基础依赖包-->
<dependency><groupId>com.xx.bigdata</groupId><artifactId>service-base</artifactId><version>${service.base.version}</version></dependency>
<!--service-base中已有依赖, 这里即可不再显式依赖lombok包-->
<!--<dependency><groupId>org.projectlombok</groupId><artifactId>lombok</artifactId>
</dependency>-->

service-b(子服务b,依赖了service-base后,由于service-base中依赖了lombok包,并且scope为compile[默认], 这里即可不再显式依赖lombok包)

<!--所有子服务工程均需要的基础依赖包-->
<dependency><groupId>com.xx.bigdata</groupId><artifactId>service-base</artifactId><version>${service.base.version}</version></dependency>
<!--service-base中已有依赖, 这里即可不再显式依赖lombok包-->
<!--<dependency><groupId>org.projectlombok</groupId><artifactId>lombok</artifactId>
</dependency>-->

以上maven工程搭建设计,主要目的是要实现尽量避免子服务不必要的重复各写各的依赖, 减少依赖重复和版本混乱问题, 实际使用下来, 好处还是显而易见的, 但是某天突然遇一个非常规的问题, 接下来详细说下这个问题.

问题描述

以上案例中的配置, 正常情况下, 编译打包时maven会自动将lombok包添加到打包文件(lib)中, 服务启动时,类加载器即可从lib中找到相应的类, 完成正常加载运行.
但最近突然出现问题,具体现象为:

某天项目Jenkins发布报错, 启动时即报类加载失败:java.lang.ClassNotFoundException
我们打开打包生成的jar包,从lib中查找,发现这个lombok丢失了
本地使用idea lifecyle中的clean packge打包后直接本地启动服务正常
本地mvn clean package 生成的jar包使用java -jar 启动与Jenkins发布结果一样报错.

这种问题最棘手之处可能在于冷门, 花了两天, 翻找了各大网站, 排查了各种可能性;都毫无进展, 甚至还试了一下时下比较火的chatGPT, 结果几番追问下来好像它也懵了, 直接给你说这样依赖不行:
在这里插入图片描述
按理说, 问题到这基本上也就只能认了, 好在保底的做法就是每个子服务分别重新显式依赖所需的jar包, 问题可以初步解决, 也算是问题不大, 无非是不好用而已.

那么最终问题如何解决的?

解决方式

通常非常规的问题, 都是非常规的原因导致, 最终解决可能也就不是什么正经的方法.
在问题发生第几天后, 每天各种尝试, 百思不得其解, 一个偶然的日志引起了我的注意, 最带来了这次问题的最终解决办法:
在某一次mvn clean package的时候,注意到一个这样的日志(不怎么起眼):

[Warnning]The POM for com.xx.bigdata:service-base:jar:1.0.1 is invalid, 
transitive dependencies (if any) will not be available, enable debug logging for more details

原来编译打包日志不会太在意, 现在黔驴技穷,无论发现个什么都觉得可疑, 尤其是这个: transitive dependencies 突然让人感觉很可能是跟这个有关!
于是,直接先问问chatGPT这个问题,看到如下答案:
在这里插入图片描述
到现在基本可以判断,大概率是这个问题导致, AI给了参考解决思路(不算太靠谱) 但是结合maven仓库结构和多人合作开发Git管理代码场景, 稍微分析就知道, 最终原因: 父工程pom结构损坏,或者有伙伴误动到了远程仓库(公司)的pom结构, 导致mvn package 部分依赖包传递失效.