Gradle构建Jar时org.gradle.jvm.version取值差异问题排查

可能的差异原因 #

1. Jenkins环境缺少JDK11工具链
   Gradle工具链会尝试自动下载或匹配配置的JDK版本，如果Jenkins服务器因网络限制、权限问题无法获取JDK11，或者本地未预安装JDK11，Gradle会回退到当前运行的JDK17进行编译，最终导致org.gradle.jvm.version被设为17。

2. Gradle版本不一致
   你本地使用Gradle 7.4.2，需检查Jenkins流水线的Gradle版本是否与之相同。低版本Gradle对Java工具链的支持可能存在缺陷，无法正确识别或应用工具链配置，进而 fallback到当前JDK。

3. release插件的执行上下文问题
   Jenkins上分为两步执行：先clean build sonarqube，再单独执行release任务。第二次执行release时，工具链配置可能未被正确加载，或者release插件的内部逻辑覆盖了工具链设置，比如部分发布插件会重新初始化项目配置，导致工具链参数丢失。

4. 环境变量或旧配置干扰
   若Jenkins构建环境中JAVA_HOME指向JDK17，且项目中存在旧的sourceCompatibility/targetCompatibility配置，可能会覆盖工具链的设置，导致编译时使用JDK17。

用于排查的Gradle参数 #

• --info：输出详细构建日志，包含Gradle查找、选择Java工具链的过程，可确认是否成功找到JDK11，或是回退到了当前JDK。
• --debug：输出更细致的调试日志，适合深入排查配置加载、插件执行的细节，比如release插件如何处理项目配置。
• javaToolchains：执行gradlew javaToolchains，列出当前环境中Gradle能检测到的所有可用Java工具链，对比本地与Jenkins的输出，即可知道Jenkins是否有JDK11工具链。
• properties：执行gradlew properties查看项目所有属性，重点检查java.toolchain.languageVersion等配置在Jenkins环境中是否正确生效。
• --dry-run：结合release任务使用，比如gradlew release --dry-run --info，可查看release任务的执行步骤，确认是否存在重新配置Java版本的操作。

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