业务场景:当前我们项目引入了公司自研的一些公共框架组件,比如SSO单点登录jar包,文件上传服务jar包等公共组件,开发新功能,本地验证好之后,部署流水线,报出一些jar包版本的整改漏洞问题,无法跑通流水线
- 通过流水线平台显示有漏洞的依赖包,逐一排查,这里存在有两种包类型,一种就是我们自己项目直接依赖的包版本问题,这些占少部分,直接修改pom文件的依赖版本号,根据内部平台查询该依赖包有哪些其他可行的版本号兼容的,就直接修改即可
- 主要问题还是在于,我们引入了多个公司自研的框架jar包,而这些jar包又引入了一些相关的jar包,这些包的版本存在漏洞问题,需要去升级这些包的依赖版本,那推动这些自研包团队去修改升级包,我们再去直接修改这个自研包版本,效果不好,他们团队需要花时间修复代码,那最后我们就利用 dependencyManagement 锁定依赖库的版本号
<!-- 漏洞修复--><dependencyManagement><dependencies><dependency><groupId>com.common.log</groupId><artifactId>log-class</artifactId><version>1.2.12</version></dependency><dependencies></dependencyManagement>
因为那些是间接依赖的包,我们无法直接像我们直接依赖的包 ,能直接去修改版本号,所以需要通过这个dependencyManagement 依赖管理标签去强制锁定,我们这个module模块中代码引用到的这些api接口功能时,才会去强制锁定使用这个指定的版本,而不会再去用引入框架jar包内的间接引用的版本了,可以说这也是一个 最短路径依赖原则,因为业务代码就是在该module工程下的,再加上是在这个模块的pom文件下定义的这个依赖管理指定版本号
直接依赖包的标签路径是:外层没有dependencyManagement
<dependencies><dependency><groupId>com.xx</groupId><artifactId>xx</artifactId><version>3.15.0</version></dependency></dependencies>
这里还有遇到一个问题,就是jar包版本升级之后,会导致以前写的一些代码会报错,这里主要原因还是因为高版本的jar包,针对某些api接口方法的形参做了一些调整,增加了一些固定的形参属性,需要传递参数,这里只能是手动去改写代码,兼容高版本,甚至可能有些导入导出的接口功能,跨版本过大,导致旧api接口都发生大改动,比如接口包名,类名,接口名,路径等等