Gradle configuration cache not enabled when executing via gradle wrapper

I use a very simple gradle project , details below.
Jdk 17
Gradle version : 8.4

gradle script

plugins {
    id 'org.springframework.boot' version '2.6.7'
    id 'io.spring.dependency-management' version '1.0.12.RELEASE'
    id 'java'

group 'org.example'
version '1.0-SNAPSHOT'

repositories {

subprojects {
    apply plugin: 'java'
    apply plugin: 'org.springframework.boot'

    dependencies {
        compileOnly 'org.projectlombok:lombok:1.18.20'
        annotationProcessor 'org.projectlombok:lombok:1.18.20'
        testImplementation 'org.junit.jupiter:junit-jupiter-api:5.8.1'
        testRuntimeOnly 'org.junit.jupiter:junit-jupiter-engine:5.8.1'

allprojects {
        println "I'm $"

dependencies {
    developmentOnly 'org.springframework.boot:spring-boot-devtools'
    testImplementation 'org.springframework.boot:spring-boot-starter-test'

test {

bootJar {
    enabled = false

jar {
    enabled = true

I have enabled usage of configuration cache via like so

# Enable configuration caching between builds.

However i can see that it comes into play only when i use gradle commands and not gradle wrapper commands. What am i doing wrong here?

Output of commands below

gradle :properties

xxxxx@xxxx-MacBook-Pro gradle-multi-module % gradle :properties
Starting a Gradle Daemon (subsequent builds will be faster)
Encryption of the configuration cache is enabled.
Calculating task graph as no configuration cache is available for tasks: :properties

When i execute gradlew though, even if it is first time invocation in the project , it does not tell me that cache is enabled or being applied

gradlew :properties

xxxxx@xxxxxxx gradle-multi-module % ./gradlew :properties      
Starting a Gradle Daemon, 3 incompatible Daemons could not be reused, use --status for details

What does ./gradlew --version say?

Btw. your build script is full of bad practices you should consider to change. Here some from a cursory look:

  • Do not use the Spring Dependency Management plugin, it is a relict from times when Gradle did not have built-in BOM support. Even its maintainer recommends not to use it anymore but instead the built-in BOM support. By now it does more harm than good.
  • Do not use subproject { ... } or allprojects { ... } or project("...") { ... }, but instead use convention plugins in buildSrc or an included build, for example implemented as precompiled script plugins.
  • Do not use “apply plugin”, but use the plugins { ... } block
  • Do not use task(...), but tasks.register to leverage task-configuration avoidance and avoid wasted time even when CC cannot be used
  • More a personal recommendation than a bad practice: Use Kotlin DSL. With that you immediately get type-safe build scripts, actually helpful error messages if you mess up syntax, amazingly better IDE support if you use a proper IDE like for example IntelliJ IDEA, and by now it is also the official default DSL.

THank you @Vampire , i will work on the script changes recommendations. The task configuration avoidance does seem interesting

My gradlew version outputs the below

Gradle 7.5.1

Build time:   2022-08-05 21:17:56 UTC
Revision:     d1daa0cbf1a0103000b71484e1dbfe096e095918

Kotlin:       1.6.21
Groovy:       3.0.10
Ant:          Apache Ant(TM) version 1.10.11 compiled on July 10 2021
JVM:          17.0.1 (Oracle Corporation 17.0.1+12-39)
OS:           Mac OS X 13.0.1 aarch64

In Gradle 7.5.1 the CC was not stable yet, so for that version the property you would need to set is named differently. But instead I’d recommend to update Gradle.

1 Like

Indeed, You are right, the flags for lower versions appear to be


If i may ask a follow up question, what is the significance of this flag,


Say for example, will it be able to convert an error to a warning no matter the error? for eg, say if i enable configuration cache, and i do task.project… in my build script, will it still ignore the error that says “nvocation of ‘Task.project’ at execution time is unsupported”

Asking since if that is the intended behavior, i am not able to see that.

It means that problems do not instantly fail the build, but it could well be that the build still does not work properly.
It is in no way meant to be used permanently.
It is only for getting more problems that might get solved while trying to make a build CC compliant.