Enabling configuration on demand causes build failure in multi module project with different group name

[kojilin]

Multi module project with different group name and org.gradle.configureondemand=true may cause

../gradlew bootRun
Configuration on demand is an incubating feature.
> Task :server:bootRunMainClassName FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':server:bootRunMainClassName'.
> Could not resolve all files for configuration ':server:runtimeClasspath'.
   > Could not find com.example.search:common:0.0.1-SNAPSHOT.
     Required by:
         project :server
         project :server > project :api

When running bootRun task of springboot plugin. The search-common project and server project has different group.

I also created the issue at gradle side before, and after gradle side's investigation, they suggest me to ask here also. see https://github.com/gradle/gradle/issues/20377#issuecomment-1102553267

Expected Behavior

It works at gradle 7.3 but failed from 7.4

Current Behavior

Failed to run bootRun task.

Context

Steps to Reproduce

Sample project at https://github.com/kojilin/demo-issue group name of server/console/main is com.example.server,search:common is com.example.search

➜  demo-public git:(main) ./gradlew :server:bootRun
Configuration on demand is an incubating feature.
> Task :server:bootRunMainClassName FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':server:bootRunMainClassName'.
> Could not resolve all files for configuration ':server:runtimeClasspath'.
   > Could not find com.example.search:common:0.0.1-SNAPSHOT.
     Required by:
         project :server
         project :server > project :api

Below 3 cases works

• run ./gradlew :console:run works(application plugin)
• Change org.gradle.configureondemand to false works
• Using the same group name works

Your Environment

Build scan URL: https://scans.gradle.com/s/vrgi7ncupnydi

[wilkinsona]

Thanks for your patience.

This doesn't work due to the changes made in #289. The problem can be worked around by downgrading to 1.0.10.RELEASE:

buildscript {
    configurations.all {
        resolutionStrategy {
            eachDependency {
                if (it.requested.group == 'io.spring.gradle') {
                    it.useVersion("1.0.10.RELEASE")
                }
            }
        }
    }
}

I think we'll have to disable the cache when configure on demand is enabled.