Skip to content

buildInfo does not work with Gradle 8.7 or later when the configuration cache is enabled #40911

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
jkuipers opened this issue May 27, 2024 · 4 comments
Labels
type: regression A regression from a previous release
Milestone

Comments

@jkuipers
Copy link

jkuipers commented May 27, 2024

After upgrading to Boot 3.3.0 I noticed that the Gradle configuration cache throws an error. This is related to the configuration of the Boot plugin's buildInfo. With this config:

plugins.withId('org.springframework.boot') {
  springBoot {
    buildInfo {
      properties {
        excludes = ['time']
      }
    }
  }
}

I'm getting this error when running Gradle with the config cache enabled:

Configuration cache state could not be cached: field `writeLock` of `org.springframework.util.function.SingletonSupplier` bean found in field `creationTime` of `org.springframework.boot.gradle.tasks.buildinfo.BuildInfoProperties` bean found in field `properties` of task `:bootBuildInfo` of type `org.springframework.boot.gradle.tasks.buildinfo.BuildInfo`: error writing value of type 'java.util.concurrent.locks.ReentrantLock'
> Unable to make field private final java.util.concurrent.locks.ReentrantLock$Sync java.util.concurrent.locks.ReentrantLock.sync accessible: module java.base does not "opens java.util.concurrent.locks" to unnamed module @d0d7a47f

Here's a project that reproduces the problem: just run a regular build to see the error.
gradle-config-cache.zip

This problem did not occur with Boot 3.2.x versions.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label May 27, 2024
@WeisSeb
Copy link

WeisSeb commented May 27, 2024

Seeing the same problem with Boot 3.2.6 and 3.3.0. Earlier versions do not have this issue.
This seems to come down to BuildInfoProperties using the SingletonSupplier of springframework.spring-core. Boot 3.2.5 comes with Spring Framework 6.1.6 where the SingletonSupplier does not have the writeLock field. Boot 3.2.6 and 3.3.0 use Spring Framework 6.1.8 where the afformentioned field exists in SingletonSupplier

Removing the buildInfo configuration or disabling the configuration cache is currently a workaround for us, but not really an optimal solution

EDIT: Boot 3.2.5 comes with Spring Framework 6.1.6 where SingletonSupplier.writeLock exists, however spring-boot-gradle-plugin:3.2.5 comes with springframework.spring-core:6.0.10 where SingletonSupplier.writeLock does not exist

@quaff
Copy link
Contributor

quaff commented May 27, 2024

I think it should be handled at Gradle side.

@jkuipers
Copy link
Author

I just tested that as a workaround, you can add this line to your gradle.properties:

org.gradle.jvmargs=--add-opens java.base/java.util.concurrent.locks=ALL-UNNAMED

@wilkinsona wilkinsona added type: regression A regression from a previous release and removed status: waiting-for-triage An issue we've not yet triaged labels May 28, 2024
@wilkinsona
Copy link
Member

Thanks, @jkuipers, and apologies for the regression. This is an unanticipated side-effect of #40074. You can also work around the problem by using Gradle 8.6 or earlier.

@wilkinsona wilkinsona changed the title Spring Boot 3.3.0 breaks Gradle configuration cache when buildInfo is configured buildInfo does not work with Gradle 8.7 or later when the configuration cache is enabled May 28, 2024
@wilkinsona wilkinsona added this to the 3.2.x milestone May 28, 2024
@wilkinsona wilkinsona modified the milestones: 3.2.x, 3.2.7 May 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: regression A regression from a previous release
Projects
None yet
Development

No branches or pull requests

5 participants