Gradle中如何将运行时类路径合理纳入编译类路径？

我的Gradle项目结构如下：

project-root/
├── adapters/
│   ├── adapter1/
│   │   ├── main
│   │   └── test
│   ├── adapter2/
│   │   ├── main
│   │   └── test
│   └── adapter3/
│       ├── main
│       └── test
└── app-spring-boot/
    ├── main
    ├── test
    └── integrationTest

在app-spring-boot模块中，适配器仅作为runtime依赖引入：

// project-root/app-spring-boot/build.gradle.kts
dependencies {
    runtimeOnly(project(":adapters:adapter1"))
    runtimeOnly(project(":adapters:adapter2"))
    runtimeOnly(project(":adapters:adapter3"))
}

我希望在app-spring-boot模块的integrationTest源码集中，不仅能在编译时直接访问app-spring-boot的所有依赖，还能访问所有引入的:adapters项目。

我使用了如下配置实现需求：

// project-root/app-spring-boot/build.gradle.kts
plugins {
    `jvm-test-suite`
}

testing {
    suites {
        val test by getting(JvmTestSuite::class)

        val integrationTest by registering(JvmTestSuite::class) {
            useJUnitJupiter()
            dependencies {
                implementation(project())
            }
            sources {
                compileClasspath += sourceSets.main.get().runtimeClasspath
            }
        }
    }
}

compileClasspath += sourceSets.main.get().runtimeClasspath确实能让所有runtimeOnly的适配器依赖在编译时可访问，但我想知道这是否是Gradle的正确且惯用的做法。

你当前的做法能实现功能，但并非Gradle推荐的惯用方式，原因在于直接将main的runtimeClasspath合并到测试的compileClasspath会打破依赖范围的语义边界：runtimeOnly原本表示依赖仅在运行时需要，而这种直接合并的方式会把main的所有runtime依赖（包括传递依赖）无差别地加到测试编译路径中，可能引入不必要的依赖，也不利于依赖关系的清晰维护。

更规范的实现方式 #

方式1：复用依赖配置（推荐）

通过自定义配置来统一管理适配器依赖，避免重复声明：

// project-root/app-spring-boot/build.gradle.kts
plugins {
    `jvm-test-suite`
}

// 自定义配置，用于统一管理适配器依赖
val adapters by configurations.creating {
    isCanBeResolved = true
    isCanBeConsumed = false
}

dependencies {
    // 将适配器依赖加入自定义配置
    adapters(project(":adapters:adapter1"))
    adapters(project(":adapters:adapter2"))
    adapters(project(":adapters:adapter3"))
    // main源码集仅在运行时使用适配器
    runtimeOnly(adapters)
}

testing {
    suites {
        val test by getting(JvmTestSuite::class)

        val integrationTest by registering(JvmTestSuite::class) {
            useJUnitJupiter()
            dependencies {
                // 依赖当前模块的main代码
                implementation(project())
                // 让测试编译时能访问适配器依赖
                implementation(adapters)
            }
        }
    }
}

这种方式既保证了main源码集仅在运行时依赖适配器，又让integrationTest源码集在编译和运行时都能访问适配器，同时避免了重复声明依赖，依赖关系清晰可控。

方式2：显式声明测试依赖

如果适配器数量不多，也可以直接在integrationTest的依赖中显式声明适配器为测试编译依赖：

testing {
    suites {
        val test by getting(JvmTestSuite::class)

        val integrationTest by registering(JvmTestSuite::class) {
            useJUnitJupiter()
            dependencies {
                implementation(project())
                // 显式声明适配器为测试编译依赖
                implementation(project(":adapters:adapter1"))
                implementation(project(":adapters:adapter2"))
                implementation(project(":adapters:adapter3"))
            }
        }
    }
}

这种方式更直观，但如果适配器数量较多或后续有变更，需要同步修改main和测试的依赖声明，维护成本稍高。

内容的提问来源于stack exchange，提问作者adriangl1997