gradle项目打成jar包 gradle 多项目 找不到依赖类

本文旨在解决Gradle多构建项目中，项目无法识别其依赖模块所引入的外部依赖的问题。通过深入解析Gradle实现和api依赖配置的区别，文章提供了两种核心解决方案：一个核心模块的内部依赖配置从实现调整为api以介绍给消费者，二是直接在消费模块中重新声明所需的外部依赖。文章详细阐述了多种方法的适用场景、优缺点，并辅以代码示例，旨在帮助开发者优化Gradle依赖管理，确保多模块项目构建的不止进行。1. 问题背景与现象分析

在gradle多项目构建中，常见的一种结构是一个或多个公共模块（如commonutils），被其他业务模块（如拦截器）所依赖。当commonutils模块引入了某些外部库（如com.google.code.gson：gson或com.rometools：rome）并使用实现配置时，虽然commonutils本身可以正常编译和运行，但其consumer拦截器在编译时却可能报错，提示无法找到这些由commonutils引入的外部依赖类。

这种现象的根本原因在于Gradle的依赖配置类型，特别是implementation和api的语义差异。implementation：表示该依赖当前模块内部使用。会被添加到当前模块的编译和运行时类路径中，但不会被引用给依赖当前模块的其他模块的编译类路径。这意味着，如果Interceptor依赖CommonUtils，并且CommonUtils 使用实现引入了 Gson，那么 Interceptor 将无法在编译时访问 Gson 的类，即使 Gson 在 CommonUtils 中 的运行时类路径中是可用的。设计有助于减少消费者的编译类路径大小，提高编译速度，并鼓励更好的规范。api：表示该依赖是当前模块公共API的一部分。它不仅会被添加到当前模块的编译和运行时类路径中，还会被传递地暴露给依赖当前模块的其他模块的编译类路径。这意味着，如果Interceptor依赖CommonUtils，并且CommonUtils使用api引入了Gson，那么Interceptor将可以在编译时直接访问 Gson 的类。

在上述问题中，Interceptor 无法识别 Gson 和 Rome，因为 CommonUtils 将它们声明为实现依赖，导致这些依赖无法传递到 Interceptor 的编译类路径中。2. 解决方案

解决此问题主要有两种策略，各有其适用场景和优缺点。2.1方案一：调整核心模块的依赖配置为api

如果被依赖的模块（如CommonUtils）确实需要将某些外部依赖作为其公共API的一部分暴露给消费者（例如，CommonUtils中的方法签名或返回类型直接使用了这些外部依赖的类），那么将这些特定的实现依赖更改为api是最直接的解决方案。

示例：修改 CommonUtils/build.gradle

假设拦截器需要访问 CommonUtils 中使用了 Gson 和 Rome 的公共方法。// CommonUtils/build.gradleplugins { id 'org.springframework.boot' version '2.2.0.RELEASE' id 'io.spring.dependency-management' version '1.0.8.RELEASE' id 'java'}// ... 其他配置 ...dependency { // 需要暴露给消费者的依赖从 'implementation' 改为 'api' api 'com.google.code.gson：gson：2.8.2' api 'com.rometools：rome：1.18.0' // 假设这个是需要暴露的 Rome 版本 // 其他内部使用的依赖仍保留 'implementation' 实现'com.itextpdf：itextpdf：5.5.13.3' 实现'org.springframework.boot：spring-boot-starter-web' // ... 其他实现依赖 ... // 对于Lombok这种只在编译阶段使用的，保持annotationProcessor annotationProcessor 'org.projectlombok：lombok：1.18.24'compileOnly 'org.projectlombok：lombok：1.18.24' // 某些情况下也可能需要compileOnly // ... 其他依赖 ...}// ... 其他配置...登录后复制

优点：配置简洁：消费者模块补充额外，自动获得依赖。符合API设计：如果这些依赖确实是模块公共API的一部分，使用api更符合语义。

矛盾：类路径膨胀：消费者模块的重复类路径会包含更多不必要的依赖，可能导致编译时间略有增加。冲突潜在：如果多个模块都通过api传递了相同依赖的不同版本，可能导致版本冲突。过度接头：如果这些依赖不是CommonUtils PublicAPI的部分，相对于内部实现细节，使用api 则构成了过度暴露，违反了信息隐藏原则。2.2方案二：在Consumer模块中重新声明所需的外部依赖

如果CommonUtils中的外部依赖不是公共API的组成部分，而只是Interceptor本身也需要用到这些依赖，那么在Interceptor模块中明确声明这些依赖是更符合其各自原则的做法。

示例：修改Interceptor/build.gradle// Interceptor/build.gradleplugins { id 'org.springframework.boot' version '2.2.0.RELEASE' id 'io.spring.dependency-management' version '1.0.8.RELEASE' id 'java'}// ... 其他配置 ...dependency { // 依赖 CommonUtils 模块实现project('：CommonUtils') // 重新声明 Interceptor 自身需要的外部依赖实现 'com.google.code.gson：gson：2.8.2'implementation 'com.rometools：rome：1.18.0' // 确定版本与 CommonUtils 中使用的兼容实现 'io.jsonwebtoken：jjwt-api：0.11.5'implementation 'io.jsonwebtoken：jjwt-api：0.11.5'implementation 'org.apache.commons：commons-io：1.3.2' 实现'org.springframework.boot：spring-boot-starter-security'实现 'org.springframework.boot：spring-boot-starter-web'compileOnly 'javax.servlet：javax.servlet-api：3.1.0'}// ...其他配置 ...登录后复制

优点：明显性：每个模块的依赖关系清晰，易于理解和维护。主要是：遵循信息原则，避免隐藏依赖转发。减少类路径： Consumer模块的编译类路径只包含其直接需要的依赖，提高效率。

差异：不一致声明：如果多个Consumer模块都需要相同的依赖，则需要多次声明，可能导致版本不一致。这可以通过在根项目或共享buildSrc中定义统一版本来满足。维护成本：当版本依赖更新时，可能需要在多个模块中同步修改。3. 最佳实践与注意事项

理解实现和api的语义：解决Gradle依赖问题的核心。始终问自己：这个依赖是当前模块公共API的一部分吗？如果不是，通常使用实现。

统一版本管理：对于多项目构建，强烈建议在根项目的build.gradle或gradle/libs.versions.toml（TOML格式的版本目录）中定义所有外部依赖的版本，并通过ext子模块中的属性或版本目录，自治区版本冲突和维护引用困难。

示例：根项目 build.gradle 中的版本管理// settings.gradlerootProject.name = 'main-project'include 'CommonUtils'， 'Interceptor'， 'SearchService'// build.gradle (根项目)subprojects { apply plugin： 'java' apply plugin： 'io.spring.dependency-management' // 保证子项目应用此插件库 { mavenCentral() // ... 其他仓库 ... } ext { gsonVersion = quot；2.8.2quot； romeVersion = quot；1.18.0quot； springBootVersion = quot；2.2.0.RELEASEquot； springCloudVersion = quot；Hoxton.SR1quot； // ... 其他常用版本 ... } dependencyManagement {imports { mavenBom quot；org.springframework.cloud：spring-cloud-dependency：${springCloudVersion}quot； } }}登录后复制

子项目引用：// CommonUtils/build.gradledependency { api quot；com.google.code.gson：gson：${rootProject.ext.gsonVersion}quot； api quot；com.rometools：rome：${rootProject.ext.romeVersion}quot； // ...}// Interceptor/build.gradledependency {implementation project('：CommonUtils')implementation quot；com.google.code.gson：gson：${rootProject.ext.gsonVersion}quot；implementation quot；com.rometools：rome：${rootProject.ext.romeVersion}quot； // ...}登录后复制

IDE同步问题： 在修改Gradle配置后，务必在IDE中（如IntelliJ） IDEA）中刷新或重新导入Gradle项目，以确保IDE的类路径与Gradle构建保持一致。有时，执行gradle clean build命令后再刷新IDE也能解决一些奇怪的编译问题。

compileOnly和runtimeOnly：compileOnly：依赖只在编译时需要，运行时由其他模块或环境提供（例如javax.servlet：javax.servlet-api，在Servlet容器中运行时提供）。runtimeOnly：依赖只在运行时需要，编译时不需要（例如JDBC驱动）。4. 总结

Gradle多项目构建中的依赖可视性问题，本质上是对实现和 api 依赖配置理解不足导致。解决此问题，开发者需要根据实际需求，权衡依赖供给性、类路径大小和级别原则。当外部依赖是模块公共 API 的一部分时，使用 api配置；否则，更推荐在消费者模块中明确规定所需的外部依赖。结合统一的版本管理策略和正确的IDE同步操作，可以有效管理复杂的多项目依赖，确保构建的稳定性和可维护性。

以上就是Gradle多项目构建中外部依赖的可见性管理与方案的详细内容，更多请关注乐常识网其他相关文章！