本文介绍了在持续集成环境中，由于未指定-Maven强制更新依赖导致的问题，强调了`-U`参数的重要性。同时，对Maven的定义、项目拆分与聚合思想、坐标定义、仓库以及jar包搜索顺序进行了详细讲解，旨在帮助读者更好地理解和运用Maven进行项目管理。
持续集成与持续交付渐渐成为不少公司保证交付质量的不二法门，朋友的公司也顺应趋势，通过maven在测试环境上手了一套。在稳定运行了一段时间后，持续集成部分场景下的案例失败率达到100%，排查后发现是由于本地仓库的某个有问题的依赖包导致的，可是公司私库中这个依赖包已经被修复上传，为什么持续集成的机器没有下载呢？让我们一起探索一下吧。
问题定位
原来该持续集成机器采用的命令是mvn clean install XXXX，缺少了一个关键的参数-U，该参数可以强制让maven在每次构建时都检查所有SNAPSHOT依赖是否更新，确保本次构建基于最新的状态。如果没有该参数，maven默认以天为单位检查依赖更新，而持续集成的频率显然比这高很多（通用的做法是代码每次提交都会触发一次构建集成），这就导致了虽然问题已修复的jar包已经上传了私库，但是当天没有触发依赖更新检查，自然该存在问题的jar包就不会被替换了，持续失败也就不可避免了。
让我们看一下正确的构建命令吧。
mvn clean deploy -B -e -U -Dmaven.repo.local=xxx-U参数前面已经解释过，接下来让我们一起看一下其他参数的含义吧。
- clean: 删除项目中已经
最低0.47元/天 解锁文章
扫一扫
1288
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
