Gradle怎么让业务模块共用基础模块-java教程-PHP中文网

必须在settings.gradle中准确include所有基础模块（如':common'、':core:network'），路径须严格匹配目录结构和大小写；业务模块通过project()声明依赖，避免循环依赖与版本不一致。

gradle怎么让业务模块共用基础模块

在 settings.gradle 中正确 include 所有基础模块

基础模块要被共用，前提是它得先被 Gradle 识别为项目的一部分。很多人只在 settings.gradle 里写了 include ':app'，却忘了把 :base、:common 这类基础模块也加进去，结果编译时报错 Project with path ':common' could not be found。

必须确保每个基础模块的目录名和 include 参数完全一致（包括冒号和大小写），且路径是相对于 settings.gradle 所在位置的相对路径：

include ':common' → 对应根目录下的 common/ 文件夹
include ':core:network' → 对应 core/network/，不是 core-network/
如果基础模块在子目录（如 libs/base），就得写 include ':libs:base'，不能省略中间层级

业务模块 build.gradle 中用 project() 声明依赖

Gradle 多模块里“共用”的本质，是让业务模块直接引用基础模块的源码工程，而不是 jar 或远端坐标。所以依赖写法必须是 project()，不是 implementation 'com.example:common:1.0' —— 后者会去 Maven 仓库找，不是本地共用。

典型写法示例（在 feature-user/build.gradle 中）：

dependencies {
    implementation project(':common')
    implementation project(':core:network')
    api project(':base')  // 注意：api 和 implementation 语义不同
}

容易踩的坑：

用了 compile（已废弃）或 api 但没声明 java-library 插件，导致传递依赖失效
基础模块本身没应用 java 或 java-library 插件，导致没有 classes 输出，业务模块编译失败
路径写成 project(':Common')（大小写不匹配），Windows 下可能侥幸通过，Linux/macOS 直接报错

避免基础模块之间循环依赖

多个业务模块共用基础模块时，最容易忽视的是基础模块自己是否形成了环。比如 :common 依赖 :base，而 :base 又反向依赖 :common，Gradle 会直接拒绝构建，报错 Circular dependency between projects。

Gradle 9.8.0

下载

判断依据很简单：打开每个基础模块的 build.gradle，检查它的 dependencies 块里有没有指向其他基础模块的 project() 引用。如果有，就要立刻拆解：

把共用逻辑上提，新建一个更底层的 :foundation 模块
用接口抽象 + 依赖反转，让 :base 依赖 :common 的接口，而非实现
确认 :common 真的需要 :base 的功能——很多时候只是误引入

统一版本与插件配置，防止 build.gradle 冗余

当十几个业务模块都依赖同一个 :common，但各自 build.gradle 里又重复写 java { toolchain { languageVersion = JavaLanguageVersion.of(17) } }，不仅难维护，还容易因某处漏改导致编译不一致。

推荐做法是在根项目的 build.gradle 中用 subprojects 或 allprojects 统一注入：

subprojects {
    apply plugin: 'java-library'
    java {
        toolchain { languageVersion = JavaLanguageVersion.of(17) }
    }
    repositories { mavenCentral() }
}

注意区别：