本文旨在解决gradle项目中jar任务无法在预期位置生成jar包的问题，并探讨java cli应用的推荐分发方式。核心内容包括：解释jar包实际输出路径（尤其是在多项目或特定插件配置下），以及对比不同分发策略（如installdist、自包含jar、jlink和graalvm原生镜像），帮助开发者高效构建和部署java命令行工具。
Gradle项目JAR包输出路径解析
在使用Gradle构建Java项目时，开发者通常会期望通过执行gradlew jar命令在项目根目录下的build/libs目录中找到生成的JAR包。然而，在某些特定配置下，即使构建成功，该目录也可能为空，导致开发者误以为JAR包未生成。
常见误区：JAR包位置的偏差
这种现象通常发生在以下两种情况：
- 多项目构建 (Multi-Project Build)：如果你的项目是一个多项目构建，并且application插件或生成JAR包的逻辑是应用于某个子项目（例如，名为app的子项目），那么生成的JAR包将位于该子项目的构建输出目录中，即app/build/libs，而不是根项目的build/libs。
- 特定插件行为：某些Gradle插件，特别是application插件，在配置时可能会影响最终产物的输出路径。虽然jar任务本身通常在应用插件的项目根目录下生成JAR，但如果项目结构或配置导致主应用逻辑被视为一个独立的模块或子项目，其JAR包的实际路径会相应调整。
示例分析
考虑以下build.gradle.kts配置：
plugins {
// 应用application插件以支持构建Java CLI应用。
application
id("com.diffplug.spotless") version "6.12.0")
}
repositories {
// 使用Maven Central解析依赖。
mavenCentral()
}
dependencies {
// 使用JUnit测试框架。
testImplementation("junit:junit:4.13.2")
// 应用所需依赖。
implementation("com.google.guava:guava:30.1-jre")
implementation("info.picocli:picocli:4.7.0")
annotationProcessor("info.picocli:picocli-codegen:4.7.0")
implementation("io.vavr:vavr:0.10.4")
}
application {
// 定义应用的主类。
mainClass.set("testlauncher.command.Runner")
}
subprojects {
apply {
plugin("com.diffplug.spotless")
}
}
spotless {
java {
importOrder()
removeUnusedImports()
googleJavaFormat()
}
}
project.tasks.findByName("build")?.dependsOn(project.tasks.findByName("spotlessApply"))在这个示例中，application插件被应用于当前项目。通常情况下，jar任务会在此项目的build/libs目录下生成JAR。然而，如果项目结构实际是一个更复杂的父子结构，或者IDE（如IntelliJ IDEA）创建项目时默认生成了类似于app这样的子模块，那么即使build.gradle.kts看起来是为根项目配置的，实际的JAR也可能被放置在app/build/libs中。
解决方案
当遇到gradlew jar成功执行但JAR包不在预期位置时，最直接的解决方案是：
- 检查子项目目录：仔细检查所有可能的子项目目录，例如./app/build/libs、./main/build/libs等。
- 查看Gradle构建日志：Gradle的构建日志通常会清晰地指示生成文件的路径。
- 使用gradlew tasks --all检查任务输出：运行gradlew tasks --all可以列出所有任务及其描述，有时可以从中找到JAR任务的输出路径信息。
Java CLI应用的推荐分发方式
将Java命令行界面（CLI）应用分发给用户，通常不只是简单地提供一个JAR包。以下是几种常见且推荐的分发策略：
-
自包含的发行版 (gradlew installDist)application插件提供了一个非常方便的任务：installDist。执行gradlew installDist会在build/install/<project-name>目录下生成一个完整的发行版，其中包含：
- 一个可执行脚本（.bat文件用于Windows，shell脚本用于Linux/macOS），用于启动应用。
- 应用JAR包及其所有依赖的JAR包。
- 这种方式用户只需下载并解压，即可直接运行，无需手动配置Java运行时环境路径。
优点：
- 用户友好，开箱即用。
- 包含所有依赖，避免依赖冲突。
- 支持跨平台脚本。
缺点：
- 发行包体积相对较大，因为它包含了所有依赖。
- 仍然需要用户系统安装Java运行时环境（JRE）。
-
胖JAR (Fat JAR / Uber JAR) 胖JAR是将应用程序代码及其所有依赖打包到一个独立的JAR文件中。虽然application插件默认生成的JAR不包含所有依赖，但可以通过配置shadow插件或spring-boot-gradle-plugin等来实现。
优点：
- 单个文件，分发简单。
- 无需单独管理依赖。
缺点：
- 文件体积大。
- 可能存在依赖冲突（如果不同依赖库使用了相同名称但版本不同的类）。
- 仍然需要用户系统安装Java运行时环境。
-
使用jlink创建自定义运行时镜像 (JDK 9+) 对于JDK 9及更高版本，可以使用jlink工具创建只包含应用程序所需模块的自定义JRE。这可以显著减小运行时环境的体积，并将其与应用程序打包在一起，形成一个完全自包含的发行版。
优点：
- 完全自包含，用户无需安装JRE。
- 运行时体积最小化。
- 启动速度可能更快。
缺点：
- 构建过程相对复杂。
- 生成的发行版平台特定。
- 需要JDK 9或更高版本。
-
GraalVM原生镜像 (Native Image) GraalVM可以将Java应用程序编译成独立的、平台特定的原生可执行文件。这意味着应用程序不再需要JVM，可以直接在操作系统上运行，启动速度极快，内存占用低。
优点：
- 极快的启动速度和低内存占用。
- 无需JVM，完全原生可执行。
- 单个文件，易于分发。
缺点：
- 编译时间较长。
- 对某些高级JVM特性（如反射、动态代理）需要额外配置。
- 生成的发行版平台特定。
- 需要GraalVM环境。
总结与建议
在Gradle项目中，如果gradlew jar未在build/libs找到JAR包，请首先检查是否存在子项目结构，并在相应的子项目build/libs目录下查找。
对于Java CLI应用的分发，推荐根据实际需求选择：
- 对于大多数场景，使用gradlew installDist生成自包含的发行版是最佳选择，它兼顾了用户友好性和开发便捷性。
- 如果对包体积和启动速度有极高要求，且目标平台明确，可以考虑jlink或GraalVM原生镜像。
- 简单的内部工具，一个胖JAR也可能是可接受的方案。
理解Gradle的构建机制和不同分发方式的优缺点，将帮助开发者更高效地构建和部署高质量的Java命令行应用程序。
