使用dependency:purge-local-repository导致Jenkins构建依赖解析错误

问题根源分析 #

你的场景里，my-internal-api的构建目标包含dependency:purge-local-repository，这个Maven插件会清理本地仓库里的指定依赖（默认是当前项目的所有依赖）。而my-services刚被前一个任务安装到本地仓库，紧接着就被这个purge操作删掉了，导致my-internal-api在install阶段找不到必需的依赖，直接触发报错。

可行解决方案 #

1. 让purge操作跳过my-services依赖

修改my-internal-api的Maven命令，给dependency:purge-local-repository添加排除参数，保留你需要的依赖：

dependency:purge-local-repository -DexcludeGroupIds=你的服务groupId -DexcludeArtifactIds=my-services clean install

把你的服务groupId替换成my-services实际的groupId，这样purge只会清理其他无关依赖，不会动刚构建好的my-services。

2. 移除purge目标，改用更适配串行构建的清理方式

如果不是必须要清理本地仓库，其实clean install已经会清理当前项目的target目录，足够保证构建的干净度。如果担心旧缓存影响：

• 可以在父任务my-build-all的最开始，统一执行一次dependency:purge-local-repository（记得排除两个子项目的依赖，避免把还没构建的依赖清掉）
• 或者给install命令加上-U参数，强制Maven更新快照依赖（如果my-services是快照版本的话）：

clean install -U

3. 调整依赖获取方式，脱离本地仓库限制

可以让两个子任务通过Jenkins工件库传递依赖，而不是依赖本地仓库：

• 在my-services任务中，构建完成后把jar包和pom文件上传到Jenkins的工件存储（比如使用Maven Deploy插件）
• 在my-internal-api任务中，配置Maven从Jenkins工件库拉取my-services的最新构建产物，这样就算清理本地仓库，也不会影响依赖的获取。

额外排查建议 #

你可以去my-internal-api的构建日志里找purge步骤的输出，确认是否真的删除了my-services相关的文件，这能帮你更精准地验证问题根源。

内容的提问来源于stack exchange，提问作者Kashyap