老炮踩坑录 · 番外篇 · 翻车现场系列基于「基础企业档案」真实项目代码复盘一次同事 deploy 了新 SNAPSHOT我本地怎么构建都是旧代码的排查关键词SNAPSHOT · updatePolicy · maven-metadata.xml · -U · _remote.repositories 欢迎阅读个人主页知守观我的专栏老炮踩坑录当前内容Maven更新策略文章目录前言现象他说 deploy 了我这边没变排查clean、强制更新、等挨个试了一遍mvn clean 和这件事没关系第二天daily 策略该过期了还是没变-U 强制更新日志里什么动静都没有定位本地仓库目录下的三个文件原因更新检查之前还有一道来源校验修复这个坑为什么难排查自查清单老炮点评前言番外篇讲了改完 common 模块忘了 install、打出来的包是旧逻辑的事。install 解决的是本地源码到本地仓库这一段。本地仓库再往上游走还有一段路同事的代码到我的本地仓库中间隔着公司私服。这一段我翻过车翻了三天。还是 base-archives 那个项目还是D:\Maven\repertory那个仓库。时间线接着番外篇往后两周。现象他说 deploy 了我这边没变当时 common 模块有个 bug行政区划编码在某种入参下处理不对同事领了修复任务。下午四点多他在群里说改完了deploy 到私服了版本号不变还是0.0.1-SNAPSHOT让我本地验证一下。我拉了他最新代码确认改动内容然后构建我自己的工程跑验证用例。bug 还在。同事的第一反应是自己没 deploy 成功又 deploy 了一次并截图发我BUILD SUCCESS。我这边重新构建结果 bug 还在。到下班我也没搞明白。第二天我继续折腾-U也用了还是没用。第三天上午我把本地仓库里 common 的目录整个删了重新构建新逻辑出来了。问题解决了但解决得莫名其妙。我把删除前备份的目录翻出来对比才搞明白这三天卡在哪里。排查clean、强制更新、等挨个试了一遍mvn clean 和这件事没关系第一天下班前我执行得最多的命令是mvn clean package。直觉上没拿到新代码就该 clean 一下。clean 只清各模块的target目录编译产物删掉重来。本地仓库在D:\Maven\repertoryclean 根本不碰它——执行完 clean本地仓库里的 jar 一个都不会少。这么想的不止我一个一起排查的同事当时也建议我再 clean 一次试试。第二天daily 策略该过期了还是没变当晚我回家想了下SNAPSHOT 有个更新检查策略 updatePolicy默认 daily24 小时内不重复检查远程。第一天的现象用它解释得通我早上构建过一次检查过了下午同事 deploy还在 24 小时窗口内不检查继续用本地缓存。那睡一觉到第二天超过 24 小时总该检查了吧。第二天上午构建bug 还在。-U 强制更新日志里什么动静都没有不等了上强制参数mvn clean package -U -DskipTests-U即 --update-snapshots跳过 updatePolicy 的时间窗口每次都检查远程 SNAPSHOT 有没有更新。构建成功。跑验证还是旧行为bug还在。回头看构建日志关于 common 这个依赖一行下载记录都没有。正常情况下 -U 检测到远程有更新日志里会有Downloading和Downloaded。我这里连 metadata 的下载记录都没有Maven 压根没去远程问。到这一步可以确定问题不在时间策略在更新前面的某个环节Maven 直接跳过了整个更新检查。定位本地仓库目录下的三个文件去D:\Maven\repertory\cn\xiaomayi\base-archives-common\0.0.1-SNAPSHOT看SNAPSHOT 目录下除了 jar 和 pom还有几个平时注意不到的文件maven-metadata-nexus.xml maven-metadata-nexus.xml.sha1 resolver-status.properties _remote.repositories base-archives-common-0.0.1-SNAPSHOT.jar base-archives-common-0.0.1-SNAPSHOT.pom挨个打开看。maven-metadata-nexus.xml是远程私服的元数据缓存记录这个 SNAPSHOT 当前最新版本的 timestamp 和 buildNumber。里面的时间戳是上周的——同事 deploy 的新版本信息根本没出现在这里坐实了Maven 没去远程访问过。resolver-status.properties记录上次检查时间maven-metadata-nexus.xml.lastUpdated1665478800000daily 策略就靠它判断要不要重新检查。用 -U 之后这个时间戳刷新了说明检查动作本身执行了但检查完没去下载。_remote.repositories的内容是关键base-archives-common-0.0.1-SNAPSHOT.jarold-nexus base-archives-common-0.0.1-SNAPSHOT.pomold-nexus先说下这个文件的格式。每行一条登记信息文件名仓库id。只是个分隔符没有特殊含义右边固定为空。这两行读作jar 和 pom 是从 id 为old-nexus的仓库下载的。本地mvn install进去的 artifact仓库 id 的位置是空的形如xxx.jar。我打开当时用的 settings.xml里面 mirror 配置的 id 是nexus。对不上。原因更新检查之前还有一道来源校验_remote.repositories是 Maven 3 引入的本地仓库管理机制。每个从远程下载的 artifact都会在这个文件里记录它是从哪个仓库 id 下载的。本地mvn install进去的后面是空的。Maven 对一个本地已有的 artifact 做更新检查之前先看这个文件标记的来源仓库 id在不在当前构建配置的仓库列表里。在正常走更新流程。不在Maven 认为这个 artifact 和当前配置的仓库对不上号整个更新检查跳过——日志不打错误不报静默用旧的。两周前公司迁移私服老 Nexus 下线换了新地址。我按 wiki 换了 settings.xml新配置的仓库 id 从old-nexus改成了nexus。本地仓库里之前下载的所有 artifact_remote.repositories里记的还是old-nexus。两边的账从那天起就对不上了。大部分依赖是 release 版本不更新不触发检查相安无事。common 这个 SNAPSHOT 天天在变第一个撞上。完整的更新链路按顺序是四步未过期且无 -U已过期或 -Uid 不在当前配置id 匹配远程无更新远程有更新开始构建步骤1: 检查 updatePolicy 和 resolver-status.properties使用本地缓存, 结束步骤2: 检查 _remote.repositories 来源仓库 id静默跳过更新, 使用本地旧 jar, 结束步骤3: 下载远程 maven-metadata.xml 对比 timestamp使用本地缓存, 结束步骤4: 下载新 jar构建成功, 使用新代码网上的文章基本只讲第一步和第三步。第二步出事的时候-U 绕得过时间窗口绕不过来源校验。另外补一个相关场景如果你本地对 common 执行过mvn install_remote.repositories里后面是空的本机标记Maven 把它当本地产物同样不检查远程更新。自己 install 过一次把同事 deploy 的版本晾在一边这种翻车方式也常见。这套匹配规则的具体行为跟 Maven 版本有关我在 3.6.3 上验证的是静默跳过更新。其他版本是拒绝使用还是报警告我没逐个试过不替它们下结论。修复彻底的办法删掉本地仓库里对应的模块目录重新下载。新下载的 artifact 会用当前的仓库 id 重新登记。Remove-Item -Recurse -Force D:\Maven\repertory\cn\xiaomayi\base-archives-common临时应急-llr–legacy-local-repository让 Maven 按 Maven 2 的老规则用本地仓库忽略_remote.repositories的来源校验。mvn clean package -U -llr -DskipTests这个参数适合救急不适合长期用——来源校验本身防的是仓库串号的问题长期绕开会把本地仓库搞乱。还有一个教训层面的做法迁移私服的时候settings.xml 里仓库 id 保持不变只改 url。id 一变本地所有存量缓存的登记信息全部作废坑就埋下了。这个坑为什么难排查全程没有任何报错。-U 执行了BUILD SUCCESS日志干净。Maven 跳过一个内部流程的时候没有任何提示从输出上看一切正常。排查方向容易被第一天的时间差带偏。updatePolicy daily 是个众所周知的点第一天的现象又正好符合它第二天、第三天还用这个思路去解释就越走越远。_remote.repositories这个文件几乎没人提。它藏在每个 artifact 目录里纯文本机制写在 Maven 源码里官方文档里基本没提它。出问题之前我不知道它的存在出问题之后搜中文资料讲它的文章也不多。Maven 跳过一个内部流程的时候没有任何提示从输出上看一切正常。自查清单老炮点评Maven 的缓存设计是层层能不动就不动时间窗口挡一次来源校验挡一次本地 install 再挡一次。每一层单独看都合理叠在一起同事的代码三天到不了我手上就是真实会发生的事。排查缓存类问题别满足于换了个参数好了或者删了重下好了。好了之后回头把机制搞清楚下次再遇到不一样的症状才不用又花三天。上一篇番外篇讲了多模块没install导致打包还是旧代码这篇讲SNAPSHOT拉不到两篇都是Maven仓库机制的坑。下期预告《mirrorOf* 把私服请求拦去了公网镜像》settings.xml 里抄来一行mirrorOf*所有仓库请求都被镜像接管包括公司私服。本地能下载的依赖CI 上 404私服里明明有的包Maven 偏偏去公网镜像找。下期讲 mirror 的匹配规则以及!排除写法为什么一定要会。如果本文对你有帮助欢迎 点赞 ⭐ 收藏 关注 留言我是老炮Java 老兵仍在一线。关注「Java老炮踩坑录」看真实案例少踩坑。
