原文地址

前言

25年新的一年，那就先更新一篇技术文章吧，这个是这几天刚遇到的一个有意思的bug，记录分享一下

原因分析

在使用maven加载一个项目的时，发现maven的依赖一直无法解析，更换阿里云镜像和中央仓库都没办法解析。不能解决com.amdelamar:jhash:2.1.2

随后查看pom文件，maven依赖坐标发现没有报错，报错的是依赖中的依赖

        <dependency><groupId>io.github.talelin</groupId><artifactId>lin-cms-spring-boot-starter</artifactId><version>0.2.0-RC2</version></dependency>

是这个lin-cms-spring-boot-starter依赖里面的子依赖jhash报错。

百度这个项目依赖的依赖，是一个开源项目

文档如下：http://doc.cms.talelin.com/

最近的一次更新已经是2022年了，这个项目原作者应该已经停止维护了。

可以理解为jhash升级了版本，但是该cms开源项目没有去更新maven仓库的依赖，所以导致项目运行不成功。

但是为什么maven没有jhash的对应的2.1.2版本呢

查看maven的中央仓库，搜索jhash项目

中央仓库竟然已经下架了2.1.2版本！！！

啊这，只有升级后的2.2.0版本，但是我没办法改动依赖里面对应的依赖。

Jcenter仓库里面还有对应的版本，但是，Jcenter已经停止服务了，没办法从Jcenter下载依赖。

Jcenter 停止服务，我哭了 —— 说一说我们的迁移方案在今年的 2 月 3 日，Jcenter 运营官方发布一则通 - 掘金

解决方案

在网上寻找jhash的2.1.2版本，还好github上面保留了这个版本的发布tag

jhash的官网 J hash - Password hashing utility in Java

找到github的对应tag地址

2.1.2竟然没有给编译jar… 其他版本都有，只有2.1.2没有（内心凌乱）

竟然没有对应jar包，那就下载zip源码包，下载好重新编译一下。

打开jhash2.1.2的源代码，发现是gradle项目，好在这个依赖并不复杂

我电脑没有装gradle，那我们根据gradle反向推断maven的依赖

  <dependencies><dependency><groupId>org.apache.directory.studio</groupId><artifactId>org.apache.commons.codec</artifactId><version>1.8</version></dependency><dependency><groupId>junit</groupId><artifactId>junit</artifactId><version>4.12</version><scope>test</scope></dependency>

然后使用maven编译成jar包，再将编译好的jar包，放入本地仓库让项目解析到这个jar依赖

将jar包导入maven本地仓库命令示例：

mvn install:install-file -Dfile=jar包的位置 -DgroupId=上面的groupId -DartifactId=上面的artifactId -Dversion=上面的version -Dpackaging=jar

因为我编译好的jar在桌面，推导后命令为

mvn install:install-file -Dfile=C:\Users\25855\Desktop\jhash-2.1.2\target\jhash-2.1.2.jar  -DgroupId=com.amdelamar -DartifactId=jhash  -Dversion=2.1.2 -Dpackaging=jar

导入成功之后，我们可以查看本地仓库是否存在对应jar包

然后我们再回到最开始的项目，刷新maven缓存，再解析项目

报错解决，可以愉快运行项目了

jar包下载

jhash-2.1.2.jar下载：https://www.123865.com/s/Z7EcVv-8V8td

maven本地仓库对应下载：https://www.123865.com/s/Z7EcVv-0V8td