本文介绍如何通过 gradle 的 files() 声明方式，将本地 jar 文件作为依赖直接引入项目（无需远程仓库），并安全、可靠地复用于多个模块，适用于离线环境与资源共享场景。
本文介绍如何通过 gradle 的 files() 声明方式，将本地 jar 文件作为依赖直接引入项目（无需远程仓库），并安全、可靠地复用于多个模块，适用于离线环境与资源共享场景。
在多模块 Java/Gradle 项目中，若需共享一个已构建完成的第三方或内部 JAR（例如通用工具包、配置资源库等），且要求该 JAR 不被重新打包（如避免 Shade 插件重复嵌入）、不依赖网络拉取（支持完全离线构建），最简洁、合规的方案是将其作为文件型依赖（file dependency） 引入，而非尝试手动拷贝至 src/main/resources 或运行时动态加载。
✅ 正确做法：使用 files() 声明本地 JAR 依赖
Gradle 原生支持将任意本地文件路径声明为依赖项。只需在对应模块的 build.gradle 中添加：
dependencies {
implementation(files("libs/my-shared-utils.jar"))
}? 注意路径是相对于当前 build.gradle 文件所在目录的相对路径；也可使用绝对路径（不推荐，影响可移植性）。
? implementation 表示该 JAR 将参与编译与运行时类路径，但不会被重新打包进最终产物（区别于 shadowJar 或 fatJar），符合“仅共享、不重复嵌入”的设计目标。
若需在多个子模块中复用同一 JAR，只需在每个模块的 build.gradle 中重复上述声明（推荐将 JAR 统一存放于项目根目录下的 libs/ 文件夹，并保持路径一致）。
⚠️ 关键注意事项
- 不建议手动放入 resources/ 目录：将 JAR 放入 src/main/resources/ 会导致它被当作普通资源文件处理（如打包为 jar!/resources/my-shared-utils.jar），无法被 JVM 自动识别为类路径依赖，也无法被 Class.forName() 或模块系统解析。
- 避免运行时动态加载 JAR：问题中提到的“按版本选择最新 JAR 并运行时加载”属于高风险操作——需手动管理 URLClassLoader、处理类加载器隔离、资源可见性及潜在的 NoClassDefFoundError，极易引发不可控的 ClassLoader 问题，强烈不推荐。
-
离线构建保障：启用 Gradle 离线模式可彻底禁用远程仓库访问：
./gradlew build --offline
配合 files() 依赖，即可实现 100% 离线、可重现的构建流程。
✅ 推荐工程实践（多模块统一管理）
为提升可维护性，可在根项目 build.gradle 中定义共享依赖变量，再由子模块引用：
// root build.gradle
ext {
sharedLib = files("libs/my-shared-utils.jar")
}
subprojects {
dependencies {
implementation rootProject.ext.sharedLib
}
}这样既保证一致性，又避免重复路径硬编码。
总之，利用 Gradle 的 files() 机制引入本地 JAR 是轻量、标准、健壮的解决方案，兼顾离线能力、模块复用与构建确定性——无需复杂反射、无需自定义插件、更无需侵入运行时逻辑。
