./gradlew build 优先于 gradle build，因其通过项目自带的 Gradle Wrapper 自动下载并运行 gradle-wrapper.properties 指定的 Gradle 版本（如 8.10），避免本地安装版本不匹配导致的插件兼容或构建失败问题。
直接运行 ./gradlew build 就能完成标准构建，但实际执行前必须确认 JDK 版本、Gradle Wrapper 状态和模块范围这三个关键点。
为什么不用 gradle build 而用 ./gradlew build
本地安装的 gradle 命令可能与项目所需的 Gradle 版本不一致，导致插件兼容问题或构建失败。Rundeck 项目明确要求 Gradle 8.10（由 gradle/wrapper/gradle-wrapper.properties 中的 distributionUrl 指定），而你机器上装的可能是 7.x 或 9.x。使用 ./gradlew（Unix/macOS）或 gradlew.bat（Windows）会自动下载并调用项目锁定的版本，跳过环境差异风险。
常见错误现象：
-
Could not determine java version from '17.0.1'：不是 Java 版本不对，而是 Gradle 版本太低，不支持 JDK 17 的元数据格式 -
Plugin [id: 'org.springframework.boot', version: '3.5.16'] was not found：Gradle 版本与 Spring Boot 插件不匹配，Wrapper 才是唯一可信入口
build 任务到底做了什么
build 是一个聚合任务，它本身不干活，只依赖其他任务按序执行。对标准 Java/Kotlin 项目，它默认包含：
-
compileJava/compileKotlin：编译源码 -
processResources：拷贝配置文件等非代码资源 -
test：运行测试（含编译测试代码、执行 JUnit/Jest/Spock） -
jar/bootJar：打包成可执行 JAR（Spring Boot 项目用后者） -
check：触发静态检查（如 Checkstyle、PMD），如果项目配置了的话
注意：build 不会发布构件到仓库，也不生成 javadoc（除非显式加 javadoc 任务）；它只产出 build/libs/ 下的二进制包和 build/reports/ 下的测试报告。
跳过测试或指定模块的实用命令
日常开发中很少需要全量 build，尤其在多模块项目里。Rundeck 有 30+ 模块，全量构建耗时且没必要。
- 跳过所有测试：
./gradlew build -x test（-x表示排除 task） - 只构建某个子模块：
./gradlew :rundeckapp:build（冒号开头是模块路径，注意不能漏） - 只编译不打包：
./gradlew :core:compileJava（适合快速验证语法） - 强制重新运行某任务（忽略 up-to-date 判断）：
./gradlew :rundeckapp:bootJar --rerun-tasks
容易踩的坑：模块名大小写敏感，:RundeckApp:build 会报错；./gradlew rundeckapp:build（漏掉开头冒号）会被识别为任务名而非路径，找不到任务。
JDK 版本不匹配时的典型报错与应对
Rundeck 明确要求 JDK 17（见 gradle/java-version.gradle）。如果本地是 JDK 11 或 JDK 21，build 会直接失败，错误信息类似：
Cannot find Java 17 或 Unsupported class file major version 65（JDK 21 编译的类，Gradle 8.10 还不支持）
解决方式只有两个：
- 切换本地 JDK 到 17（推荐用
sdk use java 17.0.1-tem或 IDEA 的 Project SDK 设置） - 修改
gradle/java-version.gradle中的sourceCompatibility和targetCompatibility，但需同步改gradle.properties里的org.gradle.jvmargs，否则 Groovy 编译器会因 Metaspace 不足而 OOM
别试图靠 --no-daemon -Dorg.gradle.java.home=... 临时覆盖 —— Gradle Daemon 会缓存 JVM 配置，下次构建仍可能复用旧进程，结果不可控。
