Gradle 7.3版本添加子项目到buildscript类路径报错如何解决

报错根因 #

Gradle 7.3 版本强化了项目配置阶段的状态流转校验规则，禁止同一时间多个项目同时进入配置流程。原有配置中直接在subprojectB的buildscript块声明project(':subprojectA')作为构建类路径依赖时，Gradle需要先完成subprojectA的配置才能拿到其产出构件，但此时subprojectB自身正处于配置过程中，两者状态冲突就会触发Cannot transition to state Configure as already transitioning to this state.报错。

适配方案 #

方案1：迁移构建逻辑到buildSrc目录（最推荐，无额外配置） #

如果subprojectA仅用于提供构建所需的自定义插件、任务类、工具逻辑，无业务侧产出，可直接将subprojectA的代码迁移到根项目的buildSrc/src/main/[groovy/kotlin/java]目录下（对应代码语言选择目录）。
Gradle会默认优先构建buildSrc下的代码，并自动将其加入所有子项目的构建类路径，不需要在subprojectB的buildscript中额外声明依赖，从根源规避配置阶段冲突。

方案2：使用复合构建引入subprojectA #

如果subprojectA同时有业务侧产出，无法迁移到buildSrc，可通过复合构建的方式解耦配置依赖：

1. 移除subprojectB的build.gradle中原有buildscript块下的classpath project(':subprojectA')配置
2. 在根项目的settings.gradle中添加复合构建声明：

includeBuild('./subprojectA') {
    dependencySubstitution {
        // 替换为subprojectA实际的maven坐标
        substitute module('com.yourorg:subprojectA') with project(':')
    }
}

3. 在subprojectB的buildscript块中按正常第三方依赖的方式声明subprojectA依赖即可：

buildscript {
    dependencies {
        // 替换为subprojectA实际的maven坐标和版本
        classpath 'com.yourorg:subprojectA:1.0.0'
    }
}

方案3：临时兼容配置（不推荐长期使用） #

如果需要快速适配不想调整架构，可在根项目的gradle.properties中添加以下配置关闭相关校验：

org.gradle.configuration-cache=false
org.gradle.unsafe.configuration-precompiled-scripts=false

该方案仅为临时绕过手段，后续Gradle高版本可能会移除相关兼容开关，建议尽快按方案1或2完成架构适配

方案4：调整为普通业务依赖（仅适用于非构建逻辑场景） #

如果subprojectA的构件是subprojectB的编译/运行时业务依赖，而非构建过程中需要用到的类路径依赖，不需要放在buildscript块中，直接在subprojectB的依赖块声明即可，不会触发配置冲突：

dependencies {
    implementation project(':subprojectA')
}

内容的提问来源于stack exchange，提问作者Sam Jing Wen