gradle assemble error: "Value for metadata of project :project2 has not been calculated yet"

[mareden]

When upgrading from gradle 7.3.3 to 7.4.1, an existing project execution (command is './gradlew clean assemble') reports following error:
Value for metadata of project :project2 has not been calculated yet

Expected Behavior

It's expected that the gradle assemble task succeeds without the issue.

Current Behavior

Gradle assemble task reports the mentioned error, and stops running. Output:

FAILURE: Build failed with an exception.

* Where:
Build file '/Users/myusername/projects/test-project/project2/build.gradle' line: 6

* What went wrong:
A problem occurred evaluating project ':project2'.
> Could not resolve all dependencies for configuration ':project2:testRuntimeClasspath'.
   > Value for metadata of project :project2 has not been calculated yet.

Context

gradle 7.3.3 works well, but gradle 7.4.1 has this issue.

Steps to Reproduce

Steps to reproduce:

1. create a gradle project with 2 sub-projects (say project1, and project2, and project1 has a dependency on project2). Gradle version is 7.4.1.
   java-test-fixtures plugin is used by all the projects, and jmockit dependency is used by both sub-projects.
2. parent project build script is:

plugins {
    id "java"
    id "java-test-fixtures"
}

subprojects {
    apply plugin: "java"
    apply plugin: "java-test-fixtures"

    group = "com.test"
    version = "1.0.0-SNAPSHOT"
}

4. 1st sub-project(project1) build script:

dependencies {
    implementation project(":project2")

    testImplementation "org.jmockit:jmockit:1.49"
}

test {
    jvmArgs "-javaagent:${classpath.find { it.name.contains("jmockit") }.absolutePath}"

    testLogging {
        events "passed", "skipped", "failed", "standardOut", "standardError"
    }
}

5. 2nd sub project (prject2) build script:

dependencies {
    testImplementation "org.jmockit:jmockit:1.49"
}

test {
    jvmArgs "-javaagent:${classpath.find { it.name.contains("jmockit") }.absolutePath}"
}

6. run gradle task then:

./gradlew clean assemble

7. see result with error:

test-project ./gradlew clean assemble

FAILURE: Build failed with an exception.

* Where:
Build file '/Users/myusername/projects/test-project/project2/build.gradle' line: 6

* What went wrong:
A problem occurred evaluating project ':project2'.
> Could not resolve all dependencies for configuration ':project2:testRuntimeClasspath'.
   > Value for metadata of project :project2 has not been calculated yet.

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

* Get more help at https://help.gradle.org

Please download and run gradle task with the attached example project prepared to reproduce the issue:
test-project.tar.gz

Your Environment

Environment information:

Component	Environment
Operating system	macOS 12.3 (aarch64)
CPU cores	8 cores
Max Gradle workers	8 workers
Java runtime	Azul OpenJDK Runtime Environment 1.8.0_322-b06
Java VM	Azul OpenJDK 64-Bit Server VM 25.322-b06 (mixed mode)
Max JVM memory heap size	455.5 MiB
Locale	Chinese (China)
Default charset	UTF-8

[YaoWang0515]

I'm having a similar problem. What's the reason? Do I need to adapt 7.4 to make any changes?

[HaasJona]

I'm also affected. Please let me know if there's anything I could try to give you more info about the problem.

[epxilinx]

I am seeing this issue intermittently as well on linux (appears to be some sort of configuration race condition). Any update on this?

[YaoWang0515]

I'm having a similar problem. What's the reason? Do I need to adapt 7.4 to make any changes?

This appears to be due to configuration resolving performed during sync. Is this not supported now or for some other reason? What should do if I need to use the result of configuration.resolve() for task increments?If any update on this,please reply.

[Fangyu0823]

This should be a bug in 7.4. Module dependencies need to be in alphabetical order. There are two ways to avoid this problem.

1、
You need to add "project.evaluationDependsOn(project.getRootProject().findProject("project2").getPath())" to build.gradle in project1.

4. 1st sub-project(project1) build script:

dependencies {
    implementation project(":project2")

    testImplementation "org.jmockit:jmockit:1.49"
}
project.evaluationDependsOn(project.getRootProject().findProject("project2").getPath())
test {
    jvmArgs "-javaagent:${classpath.find { it.name.contains("jmockit") }.absolutePath}"

    testLogging {
        events "passed", "skipped", "failed", "standardOut", "standardError"
    }
}

2、
Change the name of “project2“” to “”aaa”.

[YaoWang0515]

This should be a bug in 7.4. Module dependencies need to be in alphabetical order. There are two ways to avoid this problem.

1、 You need to add "project.evaluationDependsOn(project.getRootProject().findProject("project2").getPath())" to build.gradle in project1.

4. 1st sub-project(project1) build script:

dependencies {
    implementation project(":project2")

    testImplementation "org.jmockit:jmockit:1.49"
}
project.evaluationDependsOn(project.getRootProject().findProject("project2").getPath())
test {
    jvmArgs "-javaagent:${classpath.find { it.name.contains("jmockit") }.absolutePath}"

    testLogging {
        events "passed", "skipped", "failed", "standardOut", "standardError"
    }
}

2、 Change the name of “project2“” to “”aaa”.

I also resolved the problem in that way.

[mareden]

This should be a bug in 7.4. Module dependencies need to be in alphabetical order. There are two ways to avoid this problem.

1、 You need to add "project.evaluationDependsOn(project.getRootProject().findProject("project2").getPath())" to build.gradle in project1.

4. 1st sub-project(project1) build script:

dependencies {
    implementation project(":project2")

    testImplementation "org.jmockit:jmockit:1.49"
}
project.evaluationDependsOn(project.getRootProject().findProject("project2").getPath())
test {
    jvmArgs "-javaagent:${classpath.find { it.name.contains("jmockit") }.absolutePath}"

    testLogging {
        events "passed", "skipped", "failed", "standardOut", "standardError"
    }
}

2、 Change the name of “project2“” to “”aaa”.

As a workaourd solution, this works in my environment also.

[HaasJona]

This issue still happens with Gradle 7.5.

[lzlwzs04]

We did not met the issue in 7.4.2, but in 7.5.

[Pytry]

It's happening in 7.5.1 as well. I notice that it does not happen if I leave out the jmockit javaagent parameter to the JVM for the test task, but leave in the gradle dependency on jmockit.

Edit: You would only need to remove it for one of the projects, and it does not matter which one.

[Pytry]

I discovered that the reason it fails is because the "test" task is getting instantiated and configured when evaluating the testFixtures source sets; this happens even when using the on demand method of configuration tasks.named("test", Test){}. This is an issue because when we setup the jmockit java agent inside the configuration of "test", the classpath for the test source-set of the same subproject hasn't been calculated yet, which results in the meta-data error.

Another workaround is to place the jvmargs configuration inside of a doFirst section like so:

//Note: Using kotlin DSL
tasks.named<Test>("test") {
  doFirst {
    val path = classpath.find({
      it.name.contains("jmockit")
    })?.absolutePath
    jvmArgs("-javaagent:${path}")
  }
  //The rest of the configuration as needed like
  useJUnitPlatform()
  //etc
}

This has to go into the subprojects that are providing the testFixture sources.

So the real fix for this would be to find out why the test task is getting instantiated and configured when the testFixture sources are getting built and prevent that from happening.

[HaasJona]

This seems to still happen with Gradle 8.

[mareden]

Same issue happens still with Gradle 8.1.

[ov7a]

Sorry for the late reply.

Thank you for providing a valid report.

The issue is in the backlog of the relevant team, but this area of Gradle is currently not a focus one, so it might take a while before a fix is made.

---

Can anyone confirm that it's still an issue in 8.4?

[HaasJona]

Yes, this is still an issue in Gradle 8.4.

Welcome to Gradle 8.4!
Here are the highlights of this release:
 - Compiling and testing with Java 21
 - Faster Java compilation on Windows
 - Role focused dependency configurations creation
For more details see https://docs.gradle.org/8.4/release-notes.html
Starting a Gradle Daemon (subsequent builds will be faster)
FAILURE: Build failed with an exception.
* What went wrong:
A problem occurred configuring project ':subprojects:de.bsvrz.dav.daf'.
> Could not resolve all dependencies for configuration ':subprojects:de.bsvrz.dav.daf:testRuntimeClasspath'.
   > A problem occurred configuring project ':subprojects:de.kappich.pat.testumg'.
      > Could not resolve all dependencies for configuration ':subprojects:de.kappich.pat.testumg:runtimeClasspath'.
         > A problem occurred configuring project ':subprojects:de.bsvrz.dav.dav'.
            > Could not resolve all dependencies for configuration ':subprojects:de.bsvrz.dav.dav:runtimeClasspath'.
               > A problem occurred configuring project ':subprojects:de.bsvrz.sys.funclib.application'.
                  > Could not resolve all dependencies for configuration ':subprojects:de.bsvrz.sys.funclib.application:runtimeClasspath'.
                     > A problem occurred configuring project ':subprojects:de.bsvrz.sys.funclib.operatingMessage'.
                        > Could not resolve all dependencies for configuration ':subprojects:de.bsvrz.sys.funclib.operatingMessage:testRuntimeClasspath'.
                           > Value for metadata of project :subprojects:de.kappich.pat.testumg has not been calculated yet.

this area of Gradle is currently not a focus one

I would assume that subprojects are a basic Gradle functionality. Can you at least describe a workaround or tell us what features to avoid?

[ov7a]

@HaasJona thanks for the reply. Subprojects should work fine. At first glance, the problem is in java-test-fixtures plugin. To get a detailed description of the problem, someone needs to investigate this.

[HaasJona]

@ov7a We aren't using that plug-in.

If someone wants to investigate, the build can be accessed on https://gitlab.nerz-ev.de/ERZ/SWE_de.bsvrz.kernsoftware/-/pipelines/24121 (you might need to register, but it should otherwise be public)

[ov7a]

@HaasJona Sorry, I can't find a way to register there. Could you please upload the build as a file?

[HaasJona]

Sorry, can you try to execute the following commands?

git clone https://gitlab.nerz-ev.de/ERZ/SWE_de.bsvrz.kernsoftware.git
cd SWE_de.bsvrz.kernsoftware/
git checkout renovate/gradle-8.x
./gradlew build

[ov7a]

@HaasJona Yeah, I can download it, thanks.

[big-guy]

I think the issue is that there's a circular evaluation order introduced by lines like this:

    jvmArgs "-javaagent:${classpath.find { it.name.contains("jmockit") }.absolutePath}"

This causes the classpath of the Test task to be evaluated at configuration time, which in turns evaluates the testRuntimeClasspath, which requires the metadata of the current project to be calculated.

In #20330 (comment), you can see we're resolving a configuration in :subprojects:de.kappich.pat.testumg and end up revisiting that project in a later resolution step. This causes a cycle and this error occurs.

The underlying problem is that you need to avoid dependency resolution at configuration time. In this particular example, you could introduce a CommandLineArgumentProvider that uses the classpath to create the -javaagent command-line argument.