原文地址
前言
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依赖
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_116">jar包下载
jhash-2.1.2.jar下载：https://www.123865.com/s/Z7EcVv-8V8td
maven本地仓库对应下载：https://www.123865.com/s/Z7EcVv-0V8td
