如何在 Jenkins 中可靠构建含本地 JAR 依赖的 Maven 项目-java教程-PHP中文网

如何在 Jenkins 中可靠构建含本地 JAR 依赖的 Maven 项目

本文详解 Jenkins 构建失败的根本原因（systemPath 依赖路径不一致 + 资源复制配置错误），提供两种生产级解决方案：推荐使用 mvn install:install-file 统一安装至本地仓库，辅以 spring-boot-maven-plugin 的 includeSystemScope=true 配置，并指出 maven-resources-plugin 错误指向 /BOOT-INF/lib/ 的致命问题。

本文详解 jenkins 构建失败的根本原因（`systempath` 依赖路径不一致 + 资源复制配置错误），提供两种生产级解决方案：推荐使用 `mvn install:install-file` 统一安装至本地仓库，辅以 `spring-boot-maven-plugin` 的 `includesystemscope=true` 配置，并指出 `maven-resources-plugin` 错误指向 `/boot-inf/lib/` 的致命问题。

Jenkins 构建失败的核心症结在于：systemPath 依赖不具备可移植性，且 maven-resources-plugin 的配置违反 Spring Boot 打包规范。你的本地 Windows/Ubuntu 环境能成功，是因为开发机上 lib/cesiumlanguagewriter-2.20.1.jar 存在且路径可解析；而 Jenkins 工作空间（/var/lib/jenkins/workspace/qrd_back/）中，该 JAR 文件未被正确同步或路径解析失效——尤其当 mvn -f 指定父 POM 时，${project.basedir} 实际指向的是根模块目录，而非 ruoyi-admin 子模块，导致 systemPath 解析为 /var/lib/jenkins/workspace/qrd_back/lib/...（但 JAR 实际在 ruoyi-admin/lib/ 下），引发 No such file or directory 错误。

更关键的是，你在中配置了：

<resource><directory>lib</directory><targetpath>/BOOT-INF/lib/</targetpath><!-- ❌ 错误！绝对路径非法 --><includes><include>**/*.jar</include></includes></resource>

Maven 的 必须是相对路径（如 BOOT-INF/lib/），且 maven-resources-plugin 仅负责将资源复制到 target/classes 下，不参与最终 JAR/WAR 的打包逻辑。Spring Boot 的 spring-boot-maven-plugin 才负责将依赖组装进 BOOT-INF/lib/。此处硬编码 /BOOT-INF/lib/ 导致插件尝试向根文件系统写入，自然失败。

✅ 正确解法分两种，按推荐优先级排序：

方案一（强烈推荐）：将本地 JAR 安装至 Maven 本地仓库（CI/CD 友好）

此方案彻底规避路径硬编码，确保 Jenkins、团队成员、容器环境行为完全一致。

步骤 1：在项目根目录下创建安装脚本 install-local-jar.sh

Java Maven Common

Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。

下载

#!/bin/bash
# 将 lib/ 下所有 JAR 安装到本地仓库（适配 Jenkins 工作空间）
mvn install:install-file \
  -Dfile=ruoyi-admin/lib/cesiumlanguagewriter-2.20.1.jar \
  -DgroupId=cesiumlanguagewriter \
  -DartifactId=cesiumlanguagewriter \
  -Dversion=2.20.1 \
  -Dpackaging=jar \
  -DgeneratePom=true

步骤 2：修改 Jenkins 构建前执行命令 在 Jenkins 任务的 “构建” 步骤中，添加 Shell 命令：

chmod +x install-local-jar.sh
./install-local-jar.sh

步骤 3：精简 pom.xml，移除 system 依赖

<!-- 替换原 system 依赖为标准依赖 -->
<dependency><groupid>cesiumlanguagewriter</groupid><artifactid>cesiumlanguagewriter</artifactid><version>2.20.1</version></dependency>

✅ 优势：无路径风险、版本受控、可被子模块继承、Jenkins 自动识别。

方案二（临时兼容）：修复 system 依赖 + 正确打包配置

若必须保留 system 依赖，请严格修正以下两点：

① 修正 systemPath 路径（关键！）
使用 ${pom.basedir} 替代 ${project.basedir}，确保始终指向当前 POM 所在目录：

<dependency><groupid>cesiumlanguagewriter</groupid><artifactid>cesiumlanguagewriter</artifactid><version>2.20.1</version><scope>system</scope><systempath>${pom.basedir}/lib/cesiumlanguagewriter-2.20.1.jar</systempath></dependency>

② 删除错误的配置，启用 Spring Boot 插件打包支持
移除整个块（它对 JAR 依赖无效且危险），改为在中配置：

<plugin><groupid>org.springframework.boot</groupid><artifactid>spring-boot-maven-plugin</artifactid><configuration><!-- 必须开启，否则 system 依赖不会打入 BOOT-INF/lib --><includesystemscope>true</includesystemscope></configuration></plugin>

⚠️ 注意事项：

system 依赖无法传递给其他模块，仅限当前模块；
Jenkins 构建前需确保 ruoyi-admin/lib/ 目录及 JAR 文件已通过 Git 提交（.gitignore 不应忽略 lib/）；
Maven 3.5+ 已将 system scope 标记为 deprecated，长期项目请迁移至方案一或私有 Nexus 仓库。

总结：本地 JAR 引入不是“能跑就行”，而是工程可靠性的试金石。方案一通过标准化安装实现环境一致性，是 CI/CD 的黄金实践；方案二虽可救急，但需严守路径与插件配置规范。切勿再使用绝对 targetPath 或盲目信任 ${project.basedir} —— 这正是 Jenkins 与本地环境差异的根源。