尧图网页设计 
sherpa-onnx Java Gradle 集成实战JitPack 依赖声明、多模块瘦身与版本验证【免费下载链接】sherpa-onnxSpeech-to-text, text-to-speech, speaker diarization, speech enhancement, source separation, and VAD using next-gen Kaldi with onnxruntime without Internet connection. Support embedded systems, Android, iOS, HarmonyOS, Raspberry Pi, RISC-V, RK NPU, Axera NPU, Ascend NPU, x86_64 servers, websocket server/client, support 12 programming languages项目地址: https://gitcode.com/GitHub_Trending/sh/sherpa-onnx本指南以 java-api-examples/gradle-examples 中的 Gradle 示例为核心系统讲解如何在纯 JVM 桌面/服务端项目中通过 Gradle 接入 sherpa-onnx包括 JitPack 依赖仓库配置、单依赖与多模块两种声明方式、六大平台的 native 库产物选择以及从./gradlew build到./gradlew run的完整构建运行流程。阅读完成后你将能独立搭建一个可运行的 sherpa-onnx Java 工程并通过 JVM API 平台 native 库 拆分的方式将 fat jar 体积压缩约 10 倍同时学会用VersionInfo验证底层 onnxruntime 与 sherpa-onnx 的版本信息。一、示例工程结构总览gradle-examples目录是一个结构精简但五脏俱全的 Gradle Java 应用先看清它的布局再动手java-api-examples/gradle-examples/ ├── build.gradle # 依赖声明与 fat jar 打包逻辑 ├── settings.gradle # 根工程名sherpa-onnx-gradle-example ├── gradlew / gradlew.bat # Gradle Wrapper 启动脚本跨平台 ├── gradle/ │ └── wrapper/ │ ├── gradle-wrapper.jar │ └── gradle-wrapper.properties # 指定 Gradle 9.6.1 └── src/main/java/com/k2fsa/sherpa/onnx/example/ └── VersionTest.java # 唯一入口打印版本信息其中 settings.gradle 只有一行声明了根工程名sherpa-onnx-gradle-examplegradle-wrapper.properties 将 wrapper 固定到gradle-9.6.1-bin.zip这意味着即使本地没有安装 Gradle也可以借助gradlew获得一致、可复现的构建环境。仓库中另有一份使用 Kotlin DSL 的姊妹示例 gradle-kts-examples可在本指南末尾参考。二、环境前提JDK 8 或以上build.gradle中通过sourceCompatibility/targetCompatibility显式设置为JavaVersion.VERSION_1_8因此 Java 8 即可编译运行也兼容更高版本 JDKGradle 8.x 或以上也可以直接使用目录内自带的 Gradle Wrapperwrapper 实际分发版本为 9.6.1省去手动安装的步骤网络可访问JitPackjitpack.io与Maven Central因为所有 sherpa-onnx 构件都从这两个仓库拉取。三、依赖声明从 JitPack 拉取 sherpa-onnxsherpa-onnx 的 Java 构建产物通过 JitPack 发布repositories需要同时声明 Maven Central 与 JitPack 两个源repositories { mavenCentral() maven { url https://jitpack.io } }在依赖坐标中JitPack 采用com.github.{GitHub 用户/组织}:{仓库名}:{版本号}的约定。sherpa-onnx 的坐标即为com.github.k2-fsa:sherpa-onnx:v1.13.7版本号与 GitHub Release 标签一一对应。方式一单依赖Simple只需一行依赖即可把 JVM API 和所有平台的 native 库一并拉入dependencies { implementation com.github.k2-fsa:sherpa-onnx:v1.13.7 }这种方式配置成本最低适合快速原型验证但代价是产物体积巨大——它会同时携带 macOS、Linux、Windows 各架构的全部原生库。方式二多模块拆分Multi-module推荐把「JVM 核心 API」与「平台 native 库」拆成两个独立构件按需只引入目标平台的原生库dependencies { // 1. JVM 核心 API implementation com.github.k2-fsa.sherpa-onnx:sherpa-onnx-jvm:v1.13.7 // 2. 平台 native 库 —— 按目标平台二选一 implementation com.github.k2-fsa.sherpa-onnx:sherpa-onnx-native-lib-osx-aarch64:v1.13.7 }这种方式保证最终 jar 只包含运行平台需要的原生库体积大幅缩减是生产环境推荐用法。当前目录下的 build.gradle 默认采用方式二方式一的写法以注释形式保留在文件中供对照。支持的平台 native 库清单平台架构ArtifactmacOSARM64Apple Siliconsherpa-onnx-native-lib-osx-aarch64macOSx64Intelsherpa-onnx-native-lib-osx-x64Linuxx64sherpa-onnx-native-lib-linux-x64LinuxARM64sherpa-onnx-native-lib-linux-aarch64Windowsx64sherpa-onnx-native-lib-win-x64WindowsARM64sherpa-onnx-native-lib-win-arm64注意macOS ARM64 与 Linux ARM64 同样受支持Raspberry Pi、RK NPU 等嵌入式平台的 JNI 集成则主要走 android/SherpaOnnxAar 的 AAR 方案不在本桌面示例范围内。四、build.gradle 源码级解析示例的 build.gradle 核心逻辑可分四部分理解1. 应用插件并指定主类plugins { id application id java } application { mainClass com.k2fsa.sherpa.onnx.example.VersionTest }application插件提供run任务mainClass指向唯一的入口类VersionTest。2. 依赖仓库与依赖声明见上文第三节实际生效的是方式二JVM API 加上 macOS ARM64 native 库其余五个平台的 native 库均以注释形式给出便于切换目标平台时直接取消注释。3. Java 版本兼容java { sourceCompatibility JavaVersion.VERSION_1_8 targetCompatibility JavaVersion.VERSION_1_8 }确保产物可以被 Java 8 及以上版本运行。4. 自定义 fat jar 打包tasks.named(jar) { manifest { attributes(Main-Class: com.k2fsa.sherpa.onnx.example.VersionTest) } duplicatesStrategy DuplicatesStrategy.EXCLUDE from { configurations.runtimeClasspath.collect { it.isDirectory() ? it : zipTree(it) } } }将运行时 classpath 中所有依赖解压后重新打进单一 jar生成可直接java -jar运行的可执行 fat jarduplicatesStrategy EXCLUDE用于规避多构件中同名资源如 META-INF 文件冲突。五、构建与运行构建cd java-api-examples/gradle-examples # 使用 Gradle Wrapper推荐首次会自动下载 Gradle 9.6.1 ./gradlew build # 或使用系统安装的 Gradle gradle build首次构建时 JitPack 会解析com.github.k2-fsa:sherpa-onnx:v1.13.7系列构件并下载到本地 Gradle 缓存之后即可离线复用。运行# 使用 Gradle Wrapper推荐 ./gradlew run # 或使用系统 Gradle gradle run预期输出如下sherpa-onnx version: x.y.z sherpa-onnx gitSha1: ... sherpa-onnx gitDate: ...示例入口 VersionTest.java 的完整实现为public class VersionTest { public static void main(String[] args) { System.out.printf(sherpa-onnx version: %s\n, VersionInfo.getVersion()); System.out.printf(sherpa-onnx gitSha1: %s\n, VersionInfo.getGitSha1()); System.out.printf(sherpa-onnx gitDate: %s\n, VersionInfo.getGitDate()); System.out.printf(onnxruntime version: %s\n, VersionInfo.getOnnxruntimeVersion()); } }这四个静态方法来自 sherpa-onnx/java-api 模块中的VersionInfo类位于sherpa-onnx/java-api/src/main/java/com/k2fsa/sherpa/onnx/VersionInfo.java。其中getVersion()返回 sherpa-onnx 版本号getGitSha1()/getGitDate()对应构建所基于的 Git 提交哈希与日期getOnnxruntimeVersion()则返回底层推理引擎 onnxruntime 的版本——这四者组合即可精确核对当前 JVM 环境中加载的二进制来自哪个发布版本。示例中通过System.out.printf输出实际项目里完全可以在初始化时先打印版本用于排查 native 库加载不匹配等问题。六、两种方式的产物对比附录进阶README 中对两种方式产出的 fat jar 做了实测对比差异非常直观方式一单依赖方式二多模块Jar 压缩后体积约 95 MB约 9 MB解压后体积约 286 MB约 33 MB文件总数约 295约 253JVM class 文件约 236约 236内置 native 库全部平台仅 macOS ARM64JVM 层 class 文件数量一致约 236 个说明两种方式携带的 Java API 完全相同差异完全来自 native 库方式一内置了全部平台的原生二进制方式二只带目标平台一份。为什么推荐方式二体积缩减约10 倍9 MB vs 95 MB带来的直接收益是下载体积用户/构建机只需拉取目标平台的原生库启动速度JVM 启动时无需扫描、解压大量无关 native 库磁盘占用对 CI/CD 流水线产物与容器镜像尤其敏感的场景收益明显。自行验证可以按 README 中的命令在本地复现上述对比# 构建并查看 jar 体积 ./gradlew build ls -lh build/libs/*.jar # 列出 jar 中内置的 native 库 unzip -l build/libs/sherpa-onnx-gradle-example.jar | grep -E \.so$|\.dylib$|\.dll$方式一下 jar 内会同时出现.soLinux、.dylibmacOS、.dllWindows三类文件切回方式二后只会看到所声明平台的那一类本示例为 macOS ARM64 的.dylib这就是体积差异的直接来源。七、发布链路与版本协调仓库佐证从仓库根目录的 jitpack.yml 可以看到 sherpa-onnx 的 JitPack 构建脚本它以openjdk17构建并从 GitHub Releasev1.13.7下载 7 个构件1 个 AAR 1 个 JVM jar 6 个平台 native jar后通过mvn install:install-file安装到 JitPack 的本地仓库这正是本文第三节各坐标能直接使用的底层原因。构建链路上每个 native 库构件如sherpa-onnx-native-lib-osx-aarch64内部打包了对应平台的预编译二进制与 JNI 桥接层对应仓库 sherpa-onnx/jni 目录JVM API 构件sherpa-onnx-jvm则提供 sherpa-onnx/java-api 中约百个 Java 类的高层封装。因此在实践中需要留意两点版本约束JVM API 与 native 库的版本号必须一致本文统一为v1.13.7混用版本可能导致 JNI 符号不匹配需要离线部署时可先构建出 fat jar再连同build/libs下的产物一并分发运行时无需再访问 JitPack。八、横向参考Groovy DSL 与 Kotlin DSL 的选择仓库还提供了基于 Kotlin DSL 的 gradle-kts-examples它在build.gradle.kts中通过System.getProperty(os.name)与System.getProperty(os.arch)在构建期自动探测目标平台并拼接 native 库坐标省去了手动注释切换的步骤。两者依赖坐标与构件完全一致仅构建脚本语法不同特性Groovybuild.gradleKotlin DSLbuild.gradle.kts语法动态、简洁静态、类型安全IDE 支持良好优秀自动补全、重构字符串单引号或双引号仅双引号函数调用implementation ...implementation(...)属性赋值mainClass ...mainClass.set(...)适用场景存量项目新项目若你倾向零配置跨平台可直接参考 KTS 示例若希望显式控制每个平台产物例如为不同 CI 任务固定不同 native 库则本示例Groovy的手动声明方式更直观。两种方式都建议优先使用 Wrapper 保证构建环境一致。九、快速上手清单确认 JDK ≥ 8进入 java-api-examples/gradle-examples 目录检查 build.gradle 中当前启用的 native 库是否匹配你的目标平台默认 macOS ARM64不匹配则取消注释对应行执行./gradlew build完成编译与 fat jar 打包执行./gradlew run运行VersionTest核对输出的 sherpa-onnx 版本与 onnxruntime 版本迁移到自己的工程时照搬第三节的repositories与dependencies即可随后便能直接使用OfflineRecognizer、OnlineRecognizer、OfflineTts等 java-api 提供的高层类编写语音识别或语音合成业务。【免费下载链接】sherpa-onnxSpeech-to-text, text-to-speech, speaker diarization, speech enhancement, source separation, and VAD using next-gen Kaldi with onnxruntime without Internet connection. Support embedded systems, Android, iOS, HarmonyOS, Raspberry Pi, RISC-V, RK NPU, Axera NPU, Ascend NPU, x86_64 servers, websocket server/client, support 12 programming languages项目地址: https://gitcode.com/GitHub_Trending/sh/sherpa-onnx创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 sherpa-onnx Java Gradle 集成实战：JitPack 依赖声明、多模块瘦身与版本验证
sherpa-onnx Java Gradle 集成实战JitPack 依赖声明、多模块瘦身与版本验证【免费下载链接】sherpa-onnxSpeech-to-text, text-to-speech, speaker diarization, speech enhancement, source separation, and VAD using next-gen Kaldi with onnxruntime without Internet connection. Support embedded systems, Android, iOS, HarmonyOS, Raspberry Pi, RISC-V, RK NPU, Axera NPU, Ascend NPU, x86_64 servers, websocket server/client, support 12 programming languages项目地址: https://gitcode.com/GitHub_Trending/sh/sherpa-onnx本指南以 java-api-examples/gradle-examples 中的 Gradle 示例为核心系统讲解如何在纯 JVM 桌面/服务端项目中通过 Gradle 接入 sherpa-onnx包括 JitPack 依赖仓库配置、单依赖与多模块两种声明方式、六大平台的 native 库产物选择以及从./gradlew build到./gradlew run的完整构建运行流程。阅读完成后你将能独立搭建一个可运行的 sherpa-onnx Java 工程并通过 JVM API 平台 native 库 拆分的方式将 fat jar 体积压缩约 10 倍同时学会用VersionInfo验证底层 onnxruntime 与 sherpa-onnx 的版本信息。一、示例工程结构总览gradle-examples目录是一个结构精简但五脏俱全的 Gradle Java 应用先看清它的布局再动手java-api-examples/gradle-examples/ ├── build.gradle # 依赖声明与 fat jar 打包逻辑 ├── settings.gradle # 根工程名sherpa-onnx-gradle-example ├── gradlew / gradlew.bat # Gradle Wrapper 启动脚本跨平台 ├── gradle/ │ └── wrapper/ │ ├── gradle-wrapper.jar │ └── gradle-wrapper.properties # 指定 Gradle 9.6.1 └── src/main/java/com/k2fsa/sherpa/onnx/example/ └── VersionTest.java # 唯一入口打印版本信息其中 settings.gradle 只有一行声明了根工程名sherpa-onnx-gradle-examplegradle-wrapper.properties 将 wrapper 固定到gradle-9.6.1-bin.zip这意味着即使本地没有安装 Gradle也可以借助gradlew获得一致、可复现的构建环境。仓库中另有一份使用 Kotlin DSL 的姊妹示例 gradle-kts-examples可在本指南末尾参考。二、环境前提JDK 8 或以上build.gradle中通过sourceCompatibility/targetCompatibility显式设置为JavaVersion.VERSION_1_8因此 Java 8 即可编译运行也兼容更高版本 JDKGradle 8.x 或以上也可以直接使用目录内自带的 Gradle Wrapperwrapper 实际分发版本为 9.6.1省去手动安装的步骤网络可访问JitPackjitpack.io与Maven Central因为所有 sherpa-onnx 构件都从这两个仓库拉取。三、依赖声明从 JitPack 拉取 sherpa-onnxsherpa-onnx 的 Java 构建产物通过 JitPack 发布repositories需要同时声明 Maven Central 与 JitPack 两个源repositories { mavenCentral() maven { url https://jitpack.io } }在依赖坐标中JitPack 采用com.github.{GitHub 用户/组织}:{仓库名}:{版本号}的约定。sherpa-onnx 的坐标即为com.github.k2-fsa:sherpa-onnx:v1.13.7版本号与 GitHub Release 标签一一对应。方式一单依赖Simple只需一行依赖即可把 JVM API 和所有平台的 native 库一并拉入dependencies { implementation com.github.k2-fsa:sherpa-onnx:v1.13.7 }这种方式配置成本最低适合快速原型验证但代价是产物体积巨大——它会同时携带 macOS、Linux、Windows 各架构的全部原生库。方式二多模块拆分Multi-module推荐把「JVM 核心 API」与「平台 native 库」拆成两个独立构件按需只引入目标平台的原生库dependencies { // 1. JVM 核心 API implementation com.github.k2-fsa.sherpa-onnx:sherpa-onnx-jvm:v1.13.7 // 2. 平台 native 库 —— 按目标平台二选一 implementation com.github.k2-fsa.sherpa-onnx:sherpa-onnx-native-lib-osx-aarch64:v1.13.7 }这种方式保证最终 jar 只包含运行平台需要的原生库体积大幅缩减是生产环境推荐用法。当前目录下的 build.gradle 默认采用方式二方式一的写法以注释形式保留在文件中供对照。支持的平台 native 库清单平台架构ArtifactmacOSARM64Apple Siliconsherpa-onnx-native-lib-osx-aarch64macOSx64Intelsherpa-onnx-native-lib-osx-x64Linuxx64sherpa-onnx-native-lib-linux-x64LinuxARM64sherpa-onnx-native-lib-linux-aarch64Windowsx64sherpa-onnx-native-lib-win-x64WindowsARM64sherpa-onnx-native-lib-win-arm64注意macOS ARM64 与 Linux ARM64 同样受支持Raspberry Pi、RK NPU 等嵌入式平台的 JNI 集成则主要走 android/SherpaOnnxAar 的 AAR 方案不在本桌面示例范围内。四、build.gradle 源码级解析示例的 build.gradle 核心逻辑可分四部分理解1. 应用插件并指定主类plugins { id application id java } application { mainClass com.k2fsa.sherpa.onnx.example.VersionTest }application插件提供run任务mainClass指向唯一的入口类VersionTest。2. 依赖仓库与依赖声明见上文第三节实际生效的是方式二JVM API 加上 macOS ARM64 native 库其余五个平台的 native 库均以注释形式给出便于切换目标平台时直接取消注释。3. Java 版本兼容java { sourceCompatibility JavaVersion.VERSION_1_8 targetCompatibility JavaVersion.VERSION_1_8 }确保产物可以被 Java 8 及以上版本运行。4. 自定义 fat jar 打包tasks.named(jar) { manifest { attributes(Main-Class: com.k2fsa.sherpa.onnx.example.VersionTest) } duplicatesStrategy DuplicatesStrategy.EXCLUDE from { configurations.runtimeClasspath.collect { it.isDirectory() ? it : zipTree(it) } } }将运行时 classpath 中所有依赖解压后重新打进单一 jar生成可直接java -jar运行的可执行 fat jarduplicatesStrategy EXCLUDE用于规避多构件中同名资源如 META-INF 文件冲突。五、构建与运行构建cd java-api-examples/gradle-examples # 使用 Gradle Wrapper推荐首次会自动下载 Gradle 9.6.1 ./gradlew build # 或使用系统安装的 Gradle gradle build首次构建时 JitPack 会解析com.github.k2-fsa:sherpa-onnx:v1.13.7系列构件并下载到本地 Gradle 缓存之后即可离线复用。运行# 使用 Gradle Wrapper推荐 ./gradlew run # 或使用系统 Gradle gradle run预期输出如下sherpa-onnx version: x.y.z sherpa-onnx gitSha1: ... sherpa-onnx gitDate: ...示例入口 VersionTest.java 的完整实现为public class VersionTest { public static void main(String[] args) { System.out.printf(sherpa-onnx version: %s\n, VersionInfo.getVersion()); System.out.printf(sherpa-onnx gitSha1: %s\n, VersionInfo.getGitSha1()); System.out.printf(sherpa-onnx gitDate: %s\n, VersionInfo.getGitDate()); System.out.printf(onnxruntime version: %s\n, VersionInfo.getOnnxruntimeVersion()); } }这四个静态方法来自 sherpa-onnx/java-api 模块中的VersionInfo类位于sherpa-onnx/java-api/src/main/java/com/k2fsa/sherpa/onnx/VersionInfo.java。其中getVersion()返回 sherpa-onnx 版本号getGitSha1()/getGitDate()对应构建所基于的 Git 提交哈希与日期getOnnxruntimeVersion()则返回底层推理引擎 onnxruntime 的版本——这四者组合即可精确核对当前 JVM 环境中加载的二进制来自哪个发布版本。示例中通过System.out.printf输出实际项目里完全可以在初始化时先打印版本用于排查 native 库加载不匹配等问题。六、两种方式的产物对比附录进阶README 中对两种方式产出的 fat jar 做了实测对比差异非常直观方式一单依赖方式二多模块Jar 压缩后体积约 95 MB约 9 MB解压后体积约 286 MB约 33 MB文件总数约 295约 253JVM class 文件约 236约 236内置 native 库全部平台仅 macOS ARM64JVM 层 class 文件数量一致约 236 个说明两种方式携带的 Java API 完全相同差异完全来自 native 库方式一内置了全部平台的原生二进制方式二只带目标平台一份。为什么推荐方式二体积缩减约10 倍9 MB vs 95 MB带来的直接收益是下载体积用户/构建机只需拉取目标平台的原生库启动速度JVM 启动时无需扫描、解压大量无关 native 库磁盘占用对 CI/CD 流水线产物与容器镜像尤其敏感的场景收益明显。自行验证可以按 README 中的命令在本地复现上述对比# 构建并查看 jar 体积 ./gradlew build ls -lh build/libs/*.jar # 列出 jar 中内置的 native 库 unzip -l build/libs/sherpa-onnx-gradle-example.jar | grep -E \.so$|\.dylib$|\.dll$方式一下 jar 内会同时出现.soLinux、.dylibmacOS、.dllWindows三类文件切回方式二后只会看到所声明平台的那一类本示例为 macOS ARM64 的.dylib这就是体积差异的直接来源。七、发布链路与版本协调仓库佐证从仓库根目录的 jitpack.yml 可以看到 sherpa-onnx 的 JitPack 构建脚本它以openjdk17构建并从 GitHub Releasev1.13.7下载 7 个构件1 个 AAR 1 个 JVM jar 6 个平台 native jar后通过mvn install:install-file安装到 JitPack 的本地仓库这正是本文第三节各坐标能直接使用的底层原因。构建链路上每个 native 库构件如sherpa-onnx-native-lib-osx-aarch64内部打包了对应平台的预编译二进制与 JNI 桥接层对应仓库 sherpa-onnx/jni 目录JVM API 构件sherpa-onnx-jvm则提供 sherpa-onnx/java-api 中约百个 Java 类的高层封装。因此在实践中需要留意两点版本约束JVM API 与 native 库的版本号必须一致本文统一为v1.13.7混用版本可能导致 JNI 符号不匹配需要离线部署时可先构建出 fat jar再连同build/libs下的产物一并分发运行时无需再访问 JitPack。八、横向参考Groovy DSL 与 Kotlin DSL 的选择仓库还提供了基于 Kotlin DSL 的 gradle-kts-examples它在build.gradle.kts中通过System.getProperty(os.name)与System.getProperty(os.arch)在构建期自动探测目标平台并拼接 native 库坐标省去了手动注释切换的步骤。两者依赖坐标与构件完全一致仅构建脚本语法不同特性Groovybuild.gradleKotlin DSLbuild.gradle.kts语法动态、简洁静态、类型安全IDE 支持良好优秀自动补全、重构字符串单引号或双引号仅双引号函数调用implementation ...implementation(...)属性赋值mainClass ...mainClass.set(...)适用场景存量项目新项目若你倾向零配置跨平台可直接参考 KTS 示例若希望显式控制每个平台产物例如为不同 CI 任务固定不同 native 库则本示例Groovy的手动声明方式更直观。两种方式都建议优先使用 Wrapper 保证构建环境一致。九、快速上手清单确认 JDK ≥ 8进入 java-api-examples/gradle-examples 目录检查 build.gradle 中当前启用的 native 库是否匹配你的目标平台默认 macOS ARM64不匹配则取消注释对应行执行./gradlew build完成编译与 fat jar 打包执行./gradlew run运行VersionTest核对输出的 sherpa-onnx 版本与 onnxruntime 版本迁移到自己的工程时照搬第三节的repositories与dependencies即可随后便能直接使用OfflineRecognizer、OnlineRecognizer、OfflineTts等 java-api 提供的高层类编写语音识别或语音合成业务。【免费下载链接】sherpa-onnxSpeech-to-text, text-to-speech, speaker diarization, speech enhancement, source separation, and VAD using next-gen Kaldi with onnxruntime without Internet connection. Support embedded systems, Android, iOS, HarmonyOS, Raspberry Pi, RISC-V, RK NPU, Axera NPU, Ascend NPU, x86_64 servers, websocket server/client, support 12 programming languages项目地址: https://gitcode.com/GitHub_Trending/sh/sherpa-onnx创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考