1. 环境准备与项目创建在开始配置Gradle项目生成可执行JAR包之前我们需要确保开发环境已经准备就绪。首先确认你已安装最新版本的IntelliJ IDEA2025.3或更高版本和兼容的JDK推荐JDK 17。我实测发现使用旧版工具链可能会导致某些Gradle插件兼容性问题。打开IntelliJ IDEA后点击欢迎界面的New Project按钮。在弹出的对话框中选择左侧的Gradle项目类型右侧勾选Java语言支持。这里有个实用技巧如果你计划使用Kotlin开发可以同时勾选Kotlin/JVM选项这样项目会默认配置好跨语言编译环境。我最近的项目中就混合使用了Java和KotlinGradle的多语言支持确实很省心。项目命名环节建议遵循小写字母连字符的命名规范比如demo-app。这样既符合Gradle的约定也便于后续打包时的文件名处理。在Advanced Settings部分特别注意两点Gradle DSL选择Groovy目前生态支持最完善JDK版本要与你本地安装的一致。完成这些设置后点击Create按钮IDEA会自动生成项目骨架。2. 基础Gradle配置项目创建完成后我们需要重点配置build.gradle文件。这个文件相当于Gradle项目的大脑控制着整个构建流程。打开项目根目录下的build.gradle你会看到类似这样的初始内容plugins { id java } group com.example version 1.0-SNAPSHOT repositories { mavenCentral() } dependencies { testImplementation org.junit.jupiter:junit-jupiter:5.9.2 }为了让项目支持生成可执行JAR我们需要添加application插件。在plugins块中加入这一行id application这个插件会为我们自动配置主类信息和打包任务。接下来在文件末尾添加application配置块application { mainClass com.example.Main // 替换为你的主类全限定名 }这里有个常见坑点mainClass必须使用完整包路径。我遇到过好几次因为漏写包名导致JAR无法运行的情况。如果你不确定主类路径可以在IDEA中右键点击包含main方法的类选择Copy Reference获取完整路径。3. 依赖管理与胖JAR配置现代Java项目通常需要依赖大量第三方库如何确保这些依赖被打包进最终JAR是关键。Gradle提供了多种打包策略最常用的是胖JARfat jar方案它会把所有依赖都打包到单个JAR文件中。首先在dependencies块中添加你的项目依赖。例如dependencies { implementation org.apache.commons:commons-lang3:3.14.0 implementation com.google.guava:guava:32.1.3-jre testImplementation org.junit.jupiter:junit-jupiter:5.9.2 }然后添加创建胖JAR的task配置。这里推荐使用shadow插件Gradle社区最成熟的胖JAR方案在plugins块中添加id com.github.johnrengelman.shadow version 8.1.1插件安装后Gradle会新增shadowJar任务。你可以在命令行运行./gradlew shadowJar或者在IDEA右侧Gradle面板中找到Tasks→shadow→shadowJar执行。打包完成后JAR文件会生成在build/libs目录下文件名通常带有-all后缀。注意使用shadow插件时如果遇到依赖冲突可以通过shadowJar任务配置排除特定依赖shadowJar { exclude META-INF/*.SF exclude META-INF/*.DSA exclude META-INF/*.RSA }4. 多模块项目打包策略对于复杂项目我们通常会拆分为多个Gradle模块。这种情况下打包需要特别注意模块间的依赖关系。假设我们有个多模块项目结构如下my-app ├── core ├── api └── app (包含main方法)首先确保settings.gradle中包含所有模块include core, api, app然后在app模块的build.gradle中需要声明对其他模块的依赖dependencies { implementation project(:core) implementation project(:api) }打包多模块项目时有两种常见方案在根目录创建单独的distribution模块专门负责打包在包含main方法的模块如app中配置打包任务我通常推荐第二种方案因为它更符合Gradle的约定优于配置原则。只需在app模块中配置shadowJar如前所述运行时依赖会自动包含关联模块的编译结果。5. 打包优化与高级配置基础打包功能满足后我们可以进一步优化JAR包。首先是资源文件处理比如配置文件、静态资源等。Gradle默认会把src/main/resources下的文件打包进JAR但有时我们需要更精细的控制processResources { exclude **/.env filesMatching(application.yml) { filter { line - line.replace(version, project.version) } } }其次是JAR文件瘦身。通过以下配置可以排除开发环境专用依赖shadowJar { configurations [project.configurations.runtimeClasspath] minimize { exclude(dependency(org.slf4j:slf4j-api:.*)) } }对于需要附加JVM参数的情况可以在application插件中配置application { applicationDefaultJvmArgs [-Xms256m, -Xmx1g] }6. 自动化构建与持续集成将打包流程集成到CI/CD管道能显著提升开发效率。以下是GitHub Actions的配置示例name: Java CI on: [push] jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkoutv3 - name: Set up JDK 17 uses: actions/setup-javav3 with: java-version: 17 distribution: temurin - name: Grant execute permission for gradlew run: chmod x gradlew - name: Build with Gradle run: ./gradlew shadowJar - name: Upload artifact uses: actions/upload-artifactv3 with: name: executable-jar path: build/libs/*-all.jar在本地开发时可以通过IDEA的Gradle工具窗口快速执行任务。我习惯将常用的shadowJar任务添加到运行配置中点击Gradle面板右上角的Create Run Configuration图标选择对应任务即可。7. 常见问题排查即使按照最佳实践配置实际打包过程中仍可能遇到各种问题。以下是几个典型场景的解决方案问题1No main manifest attribute这表示MANIFEST.MF文件中缺少Main-Class定义。解决方法确认application插件已正确配置mainClass检查shadowJar任务是否覆盖了默认配置手动检查生成的META-INF/MANIFEST.MF文件内容问题2ClassNotFoundException通常是依赖没有正确打包。建议检查dependencies是否使用implementation而非compileOnly确认shadowJar配置包含了所有必要依赖使用jar -tf your.jar命令查看JAR内容问题3版本冲突多个依赖引入相同库的不同版本时可能引发问题。可以通过以下命令分析依赖树./gradlew dependencies然后使用exclude排除冲突依赖implementation(com.example:library:1.0) { exclude group: org.unwanted, module: conflict }8. 性能调优与最佳实践随着项目规模增长打包速度可能成为瓶颈。以下是几个提升构建效率的技巧增量构建确保任务正确声明输入输出tasks.withType(AbstractArchiveTask).configureEach { preserveFileTimestamps false reproducibleFileOrder true }构建缓存在gradle.properties中启用org.gradle.cachingtrue并行构建同样在gradle.properties配置org.gradle.paralleltrue依赖优化定期检查并移除无用依赖./gradlew dependencyUpdates对于大型项目建议采用分层构建策略将稳定模块发布到本地Maven仓库其他模块通过版本号引用避免每次都重新编译。