Is there a way to download “pom files” for the set of “groupartifactversion” in a task action or work action? Currently I have something as follows while neither

project

nor

project.dependencies

is compatible with CC:

val artifactResolutionResult = project.dependencies.createArtifactResolutionQuery()
    .forComponents(requests.map { it.first })
    .withArtifacts(MavenModule::class, MavenPomArtifact::class)
    .execute()

val results = artifactResolutionResult.resolvedComponents
    .associate { it.id to it.getArtifacts(MavenPomArtifact::class) }

I run into a behavior when using configuration cache in combination with artifact transforms I'm not sure how to wrap my head around for our test setup we want to do something like that:

FileCollection mainRuntime = mainSourceSet.getRuntimeClasspath();
FileCollection testRuntime = testSourceSet.getRuntimeClasspath();
FileCollection testOnlyFiles = testRuntime.minus(mainRuntime);
test.doFirst(task -> test.environment("es.entitlement.testOnlyPath", testOnlyFiles.getAsPath()));

ideally I would want to replace the requirement for using

test.doFirst

by replacing it with

test.environment("es.entitlement.testOnlyPath", getProviderFactory().provider(() -> testOnlyFiles.getAsPath()));

Now in theory that works okay but it breaks as soon as we enable configuration cache and have artifact transforms in declared that are registered against configurations that include internal dependencies complaining about the expected jar to transform not yet available (well it did not build yet). My understanding is that with having those configurations declared as

@InputFiles

gradle understands its buildable and does handle it as expected. Given that

environment

is

@Input

we circumvent the buildable part I assume. In this case would you just keep the doFirst block as is or do you have another idea how to solve that properly?

Folks, help my poor vacation brain. When is an input property not prematurely evaluated and serialized to the CC entry? I thought with

abstract class MyTask : DefaultTask() {
    @get:Input
    abstract val foo: Property<String>
}
val bar by tasks.registering
val baz by tasks.registering(MyTask::class) {
    foo = bar.map {
        println("Calculating foo")
        ""
    }
}

the value of

foo

should not be serialized to the CC entry, as it has a task dependency. But obviously I forgot some detail. 😕

I enabled configuration cache in my library, but for some reasons tests started failing and hanging indefinitely, so I disabled it just for the test tasks. What's the best way to debug the issue? I made a PR re-enabling configuration cache for the tests that show the failure. https://github.com/eygraber/sqldelight-androidx-driver/pull/92 Here's a scan of a failed run - https://scans.gradle.com/s/z5i2jptjvqmlg

I implement a build cache service which needs credentials for the operation. It looks like credential change invalidates configuration cache entry:

Calculating task graph as configuration cache cannot be reused because environment variable 'AWS_ACCESS_KEY_ID' has changed.

Is there a way to avoid configuration cache invalidation when credentials change?

Should we still recommend to users to write

val theirTask by tasks.registering {
    aProperty = provider { someComplexInitialization() }
}

instead of

val theirTask by tasks.registering {
    aProperty = someComplexInitialization()
}

? With the configuration cache enabled, the task will be configured eagerly anyway if

theirTask

is in the task graph, so the

provider {}

does nothing. Or is

provider {}

only for declaring things outside of tasks?

I have a question related to composite builds and configuration on demand. When you have a project that has a composite build (using includeBuild), it seems that configuration occurs on the composite build even when not referenced as a dependency in the root project. When not using a composite build and just including the projects (using include) it seems to be able to avoid some of the configuration. I'm still investigating this, but is this the case?

I've been trying to improve my configuration cache hits - I noticed that an env var used in a Sync task was busting the cache every time. I've got a version which doesn't bust the cache, but it's pretty noisy. Wondering if anyone can suggest a better solution?

Good morning chat, been a while. How exactly does Gradle instantiate objects when re-using configuration cache? Does it create them using

ObjectFactory#newInstance

(or whatever the internal version of that is) with service injection support or does it try to build the class raw using the saved values. Asking because I am using a transient private field that stores an instance of

Problems

which is normally provided through service injection in constructor parameter or bean getter.

Hi everyone Does anyone know if you can pre-generate configuration-cache for a task (

test

for example) without actually running it?

Hi! I'm seeing a configuration cache crash but I don't understand it.

Exception in thread "DefaultSharedObjectDecoder reader thread" org.gradle.api.GradleException: Could not load the value of 
  field `collection` of `kotlin.collections.builders.SerializedCollection` bean found in 
  field `_byTask` of `org.jetbrains.kotlin.gradle.targets.js.nodejs.TasksRequirements` bean found in 
  field `tasksRequirements` of `org.jetbrains.kotlin.gradle.targets.js.npm.resolver.KotlinCompilationNpmResolution` bean found in 
  field `byCompilation` of `org.jetbrains.kotlin.gradle.targets.js.npm.resolved.KotlinProjectNpmResolution` bean found in 
  field `v` of `java.util.Collections$SingletonMap` bean found in field `projects` of `org.jetbrains.kotlin.gradle.targets.js.npm.resolved.KotlinRootNpmResolution` bean found in 
  field `__resolution__` of `org.jetbrains.kotlin.gradle.targets.js.npm.KotlinNpmResolutionManager$Parameters_Decorated` bean found in Gradle runtime.
	at org.gradle.internal.serialize.graph.BeanPropertyExtensionsKt.readPropertyValue(BeanPropertyExtensions.kt:70)
	at org.gradle.internal.serialize.beans.services.BeanPropertyReader.readFieldOf(BeanPropertyReader.kt:93)
…
Caused by: java.lang.ArrayIndexOutOfBoundsException: Index 53 out of bounds for length 4
	at org.gradle.internal.serialize.codecs.core.jos.JavaObjectSerializationCodec.decode(JavaObjectSerializationCodec.kt:299)
	at org.gradle.internal.serialize.graph.codecs.BindingsBackedCodec.decode(BindingsBackedCodec.kt:92)

* What went wrong:
Could not load the value of field `__npmResolutionManager__` of task `:jsPackageJson` of type `org.jetbrains.kotlin.gradle.targets.js.npm.tasks.KotlinPackageJsonTask`.

No build scan was generated, even though they are enabled. From what I can tell, this was introduced by this commit, but I don't understand why.

Hey there i have a question regarding ignoring certain build parameter in configuration cache. We generate a random test seed that we pass to a TestTask. With configuration cache enabled this stays the same for the whole time the cache is reused. I see multiple discussions around having the option to ignore certain properties from the configuration cache explicitly in github issues but those have not been addressed for years (e.g. https://github.com/gradle/gradle/issues/20873) Did i miss a memo here? What do people do these days having this type of requirement? just not using the configuration cache?

Hello 👋 The next Gradle version, 9.1, is breaking my plugin with configuration cache. Any hint about what has changed respect to 9.0 related to that? GitHub issue: https://github.com/JavierSegoviaCordoba/semver-gradle-plugin/issues/201

Hey. I am looking into using a build service that does some logging during the execution phase. For example, logging the things that are printed to the console also into a file. The only thing I am aware of to make Gradle start such a service early outside of a task is

getEventsListenerRegistry().onTaskCompletion(myServie)

(full example). Are there any other hooks like that available? Ideally I would like to force my service to start before task execution (i.e. after CC was loaded) and not just when the first task has completed.

Hey, that should be an easy one, but I am still reading / learning about the CC + changes, so I got this code in one of my kotlin files and could need a helping hand here:

tasks.clean {
    doFirst {
        delete(layout.projectDirectory.dir("node_modules"))
    }
}

Which now fails with CC enabled, because it is a disallowed type - how do I write this in a CC compatible way? https://docs.gradle.org/9.1.0/userguide/configuration_cache_requirements.html#config_cache:requirements:disallowed_types mentions that I should replace

project.delete {}

with

FileSystemOperations.delete {}

but the latter one has to be injected on a task - is there a way to use it like:

providers.exec { }

to write something like:

providers.fs.delete(..)

or how do I replace that

doFirst / doLast

delete operation(s)?

I was searching for this but did not find any info in any of the issue trackers or docs. Does anyone know about the status/plans of supporting

org.gradle.unsafe.isolated-projects

in VS Code? Currently they add an init script that causes issues like

':app' cannot access 'Project.tasks' functionality on another project ':'

Hey, I am still working (and reading + learning) on some of my CC issues, is there a way to see which part(s) of my task are the problem (variable name, or class names, something which would give me a hint where to look) when something like this is reported:

1 problem was found storing the configuration cache.

`- Task

:models:migrateDocumentModels

of type `org.gradle.api.DefaultTask`: cannot serialize Gradle script object references as these are not supported with the configuration cache.`

See <https://docs.gradle.org/9.1.0/userguide/configuration_cache_requirements.html#config_cache:requirements:disallowed_types>

That would be really helpful - I know the report has a hierarchical view, but that one has e.g. "this$0" which is not that helpful. I've got this task at the moment, which does result in the problem found above (it calls a jar / javaexec task in a loop):

val docModelMigration: Configuration by configurations.creating

docModelMigration.isTransitive = false

dependencies {

docModelMigration(libs.tool.model.migration) {

artifact {

classifier = "jar-with-dependencies"

}

}

}

val models =

listOf(

"modelA",

"modelB"

)

val migrateDocumentModels =

tasks.register("migrateDocumentModels") {

val myModels = models.toMutableList()

val myWorkingDir = layout.projectDirectory.asFile

val classPathFiles =

files(

docModelMigration.files,

java.sourceSets.main

.get()

.resources.srcDirs,

)

doLast {

myModels.forEach { model ->

val theTask =

providers

.javaexec {

workingDir = myWorkingDir

classpath = classPathFiles

mainClass = "com.example.migration.MigratorCli"

args = listOf(model)

}

theTask.result.get().assertNormalExitValue()

println(

theTask.standardOutput.asText

.get()

.trim(),

)

}

}

}

Anyone an idea what is wrong here - I moved all those project refs (working dir, classpath file collections from the configuration) out of

doLast { }

but I am still missing something here, what I am doing wrong, hints appreciated, thx.

Hey, another CC question. I've got a task with a

doLast { }

action. As soon as I am calling a function defined in my

build.gradle.kts

, I am getting a CC violation. I could inline the whole code of that function, but I can't believe that is the correct solution. How can I call such a function without triggering a violation? A sample would be, I just made the body as small as possible:

tasks.register("npmInstall2") {
    doLast {
        if (changeLabel()) {
            println("changed")
        }
    }
}

fun changeLabel(): Boolean = false

Hints appreciated, thanks.

Hi, another question. I've read about https://docs.gradle.org/current/userguide/configuration_cache_requirements.html#dependency_management_types but having a hard time to figure out what is allowed and what not and how to move forward to a CC compatible solution, is e.g. ResolvedDependency allowed? I have this task at the moment:

project.tasks.register("checkDependencies") {
    val configurationsToCheck = mutableSetOf<Configuration>()
    listOf("compileClasspath", extension.configuration.get()).forEach { configToCheck: String ->
        configurationsToCheck += project.configurations[configToCheck]
    }

    doLast {
        val snapshotDeps = mutableListOf<String>()

        val resolvedDependencies = mutableSetOf<ResolvedDependency>()
        configurationsToCheck.forEach { configToCheck: Configuration ->
            configToCheck
                .resolvedConfiguration.firstLevelModuleDependencies
                .forEach { resolvedDependencies += it }
        }
        val sortedValues = resolvedDependencies.toMutableList()
        sortedValues.sortWith(compareBy({ it.moduleGroup }, { it.moduleName }))
        sortedValues.forEach { dep: ResolvedDependency ->
            if (dep.moduleGroup.startsWith("com.example")) {
                // body work
                Logging.getLogger("com.example").quiet("Found $dep")
            }
        }

        if (!snapshotDeps.isEmpty()) {
            throw GradleException("Found snapshot dependency: ${snapshotDeps.joinToString(separator = "\n")}")
        }
    }
}

Which does look over the 1st level declared deps on the given configurations and searches for patterns which I don't want there - this fails with CC enabled and Gradle 9. Anyone have some pointers (to the docs) / ideas how to get those info / task / work done in a CC compatible way? Thanks.

Is there a way to share the configuration cache in a CI situation?

I recently enabled parallel CC and now get errors like so:

Error while reading task graph
> Exception while loading configuration for :cache-variables-arguments: Class 'com.apollographql.apollo.gradle.task.ApolloGenerateOptionsTask' not found in class loader 'InstrumentingVisitableURLClassLoader(ClassLoaderScopeIdentifier.Id{coreAndPlugins:settings[:apollo-kotlin]:buildSrc[:apollo-kotlin]:root-project[:apollo-kotlin](export)})' of type 'org.gradle.internal.classloader.VisitableURLClassLoader$InstrumentingVisitableURLClassLoader'.

I'm like 80% sure this is related because I have never seen anything like this before enabling parallel CC. Does that ring a bell to anyone? Is there anything I can do to debug this further?

What could be reason for the

Not restoring configuration-cache state, as Gradle User Home was not fully restored

? I see

Saved cache entry with key gradle-configuration-cache-v1...

in the action that writes cache.

I don't understand how I can get this error. I am in the apply method of a plugin. The Stacktrace tells me that. This is

> Task :generatePrecompiledScriptPluginAccessors FAILED

, but only when I build my convention plugin project stand alone (not as inlcudedBuild in another project) Is this a known (?) bug or something. I am confused. 🤔 https://scans.gradle.com/s/fci624kcoiqrw

Caused by: org.gradle.api.InvalidUserCodeException: Accessing non-serializable type 'interface org.gradle.api.Project' during execution time is unsupported.
        at org.gradle.internal.configuration.problems.DefaultProblemFactory$problem$1$build$diagnostics$1.get(DefaultProblemFactory.kt:89)
        at org.gradle.internal.configuration.problems.DefaultProblemFactory$problem$1$build$diagnostics$1.get(DefaultProblemFactory.kt:89)
        at org.gradle.internal.problems.DefaultProblemDiagnosticsFactory$DefaultProblemStream.getImplicitThrowable(DefaultProblemDiagnosticsFactory.java:165)
        at org.gradle.internal.problems.DefaultProblemDiagnosticsFactory$DefaultProblemStream.forCurrentCaller(DefaultProblemDiagnosticsFactory.java:154)
        at org.gradle.internal.configuration.problems.DefaultProblemFactory$problem$1.build(DefaultProblemFactory.kt:89)
        at org.gradle.internal.cc.impl.initialization.DefaultConfigurationCacheProblemsListener.disallowedAtExecutionInjectedServiceAccessed(ConfigurationCacheProblemsListener.kt:68)
        at org.gradle.internal.dispatch.MethodInvocation.invokeOn(MethodInvocation.java:77)
        at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:28)
        at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:19)
        at org.gradle.internal.event.DefaultListenerManager$ListenerDetails.dispatch(DefaultListenerManager.java:581)
        at org.gradle.internal.event.DefaultListenerManager$ListenerDetails.dispatch(DefaultListenerManager.java:551)
        at org.gradle.internal.event.AbstractBroadcastDispatch.dispatch(AbstractBroadcastDispatch.java:84)
        at org.gradle.internal.event.AbstractBroadcastDispatch.dispatch(AbstractBroadcastDispatch.java:70)
        at org.gradle.internal.event.DefaultListenerManager$EventBroadcast$ListenerDispatch.dispatch(DefaultListenerManager.java:408)
        at org.gradle.internal.event.DefaultListenerManager$EventBroadcast$ListenerDispatch.dispatch(DefaultListenerManager.java:393)
        at org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:88)
        at jdk.proxy1/jdk.proxy1.$Proxy29.disallowedAtExecutionInjectedServiceAccessed(Unknown Source)
        at org.gradle.internal.cc.impl.ConfigurationTimeBarrierBasedExecutionAccessChecker.disallowedAtExecutionInjectedServiceAccessed(ExecutionAccessChecker.kt:31)
        at org.gradle.internal.cc.impl.InstrumentedExecutionAccessListener.disallowedAtExecutionInjectedServiceAccessed(InstrumentedExecutionAccessListener.kt:32)
        at org.gradle.internal.classpath.InstrumentedExecutionAccess.disallowedAtExecutionInjectedServiceAccessed(InstrumentedExecutionAccess.java:64)
        at org.gradlex.javamodule.packaging.JavaModulePackagingExtension_Decorated.getProject(Unknown Source)
        at org.gradlex.javamodule.packaging.JavaModulePackagingExtension.primaryTarget(JavaModulePackagingExtension.java:131)
        at org.gradlex.javamodule.packaging.JavaModulePackagingPlugin.apply(JavaModulePackagingPlugin.java:38)
        at org.gradlex.javamodule.packaging.JavaModulePackagingPlugin.apply(JavaModulePackagingPlugin.java:14)
        at org.gradle.api.internal.plugins.ImperativeOnlyPluginTarget.applyImperative(ImperativeOnlyPluginTarget.java:55)
        at org.gradle.api.internal.plugins.RuleBasedPluginTarget.applyImperative(RuleBasedPluginTarget.java:50)
        at org.gradle.api.internal.plugins.DefaultPluginManager.addPlugin(DefaultPluginManager.java:190)
        at org.gradle.api.internal.plugins.DefaultPluginManager.access$100(DefaultPluginManager.java:54)
        at org.gradle.api.internal.plugins.DefaultPluginManager$AddPluginBuildOperation.run(DefaultPluginManager.java:285)

Is there a future for configure-on-demand in a cc/project-isolation world? For projects that have a large up-front configuration time out configure-on-demand still have impacts for non-cached configuration runs? Just curious if there's been any plans (I've seen the Deprecate configure-on-demand ticket, but it doesn't seem like any particular fate was decided).

With IP, does Gradle reuse CC from projects that do not need to be reconfigured or does Gradle store 1 CC for all projects and reconfigure all projects, when eg 1 Gradle property is changed but only used in a few projects?

Does IP work with Android apps yet? AFAIK I tried last year and there were some incompatibilities . Could use the parallel configuration time, with project taking 3-3.5 mins to configure 😞

When CC fails on CI, this is the message:

See the complete report at file:///...(redacted)`

there's a bit more detail, but that's the crux of it. It would be nice if CC could be configured to emit a report directly to console for CI cases

In regards to Project Isolation, anyone else get a “too many files open” on macOS when syncing in Android studio? Not sure if it's an AS issue, Mac issue , or gradle issue

FAILURE: Build failed with an exception. * What went wrong: Execution failed for task 'gradle plugincompileKotlin'.

A failure occurred while executing org.jetbrains.kotlin.compilerRunner.GradleCompilerRunnerWithWorkers$GradleKotlinCompilerWorkAction

> Compilation error. See log for more details * 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 help.gradle.org.

BUILD FAILED in 9s error Failed to install the app. PS C:\Projects\AwesomeProject>

Our infra engineers are complaining that Gradle cache is taking 85% space of 1TB agent. It is Android multimodule project with mostly stable gradle version but we update plugins, write convention plugins and do other changes that might invalidate cache. Are there good tools/practices how to investigate next questions - is it normal that cache grows so big, why gradle cache for engineer's machine dramatically different, how much space should have build machine on CI that Gradle cache clean mechanism is sufficient to keep it workable?