Run 'flutter -h' (or 'flutter <command> -h') for available flutter commands and options. PS C:\Users\Lenovo\flutterProjects> flutter run Launching lib\main.dart on sdk gphone x86 in debug mode... FAILURE: Build failed with an exception. * What went wrong: Could not open settings generic class cache for settings file 'C:\Users\Lenovo\flutterProjects\android\settings.gradle' (C:\Users\Lenovo\.gradle\caches\7.5\scripts\3d075fs9hjp81ny0sgym4v09w).

BUG! exception in phase 'semantic analysis' in source unit '_BuildScript_' Unsupported class file major version 65

* 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 BUILD FAILED in 1s Running Gradle task 'assembleDebug'... 1,989ms ┌─ Flutter Fix ────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ │ [!] Your project's Gradle version is incompatible with the Java version that Flutter is using for Gradle. │ │ │ │ If you recently upgraded Android Studio, consult the migration guide at docs.flutter.dev/go/android-java-gradle-error. │ │ │ │ Otherwise, to fix this issue, first, check the Java version used by Flutter by running

flutter doctor --verbose

. │ │ │ │ Then, update the Gradle version specified in C:\Users\Lenovo\flutterProjects\android\gradle\wrapper\gradle-wrapper.properties to be compatible with that Java version. See the link below for more information on compatible │ │ Java/Gradle versions: │ │ https://docs.gradle.org/current/userguide/compatibility.html#java │ │ │ │ │ └──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘ Error: Gradle task assembleDebug failed with exit code 1 getting this issue

hello

Hi, can someone help me in understanding this: https://github.com/google/protobuf-gradle-plugin/pull/719/files If I am not wrong, aren't these two things effectively the same? Create a

Provider

, so that

inputFiles.files

is accessed lazily during execution, when the task action queries the fileCollection and the sources added need to be resolved.

return objectFactory.fileCollection()
        .from(providerFactory.provider { unused ->
          Set<File> files = inputFiles.files
          // use files

Use

FileCollection.getElements()

which is also just provides

Provider

for accessing inputFile.files

return objectFactory.fileCollection()
        .from(inputFiles.getElements().map { files ->
          // use files

How does the former code access

inputFiles.files

eagerly?

hi 👋 Do you disable Configuration Cache (CC) on CI? In all of our projects where we’ve enabled it, we’ve noticed that configuration time *increases*—on average by a minute, sometimes even more. I came across a discussion in Kotlin’s Gradle channel, and I understand that CC is supposed to help with task parallelization. However, in our case (across three apps), we’re not seeing any improvements—instead, we see that Gradle spends time on “Calculating task graph as no cached configuration is available for tasks.” which is not later reused. I’m curious - does this suggest an issue with our configuration, or do most of you simply disable CC on CI?

Hi! When i have enabled

org.gradle.unsafe.configuration-cache=true

in my

gradle.properties

i have problem building my project because of this error:

* What went wrong:
Unable to find build service with name 'jaxbJavaGenTss'.

Why am I facing this issue and how to resolve it? Pasting my

build.gradle.kts

file in thread

im getting an interesting bug where configuration cache misses:

Configuration on demand is an incubating feature.
Calculating task graph as configuration cache cannot be reused because an input to task ':buildSrc:compileJava' has changed.

but ive only changed code within a library module code, nothing in buildSrc. anyway to debug / diagnose?

Is there a configuration-cache/task-avoidance -acceptable way of excluding classes from jacoco reports? What I see copy-pasted mostly comes from https://stackoverflow.com/questions/29887805/filter-jacoco-coverage-reports-with-gradle, namely

jacocoTestReport {
    afterEvaluate {
        classDirectories.setFrom(files(classDirectories.files.collect {
            fileTree(dir: it, exclude: 'com/blah/**')
        }))
    }
}

but I'm wondering if there are better ways now?

Hey all, What is the correct way to make this task CC friendly?

val myCmakeTask by tasks.registering(Exec::class) {
    commandLine("cmake", "--build", "build")
    standardOutput = FileOutputStream("$buildDir/cmake-output.log")
    errorOutput = FileOutputStream("$buildDir/cmake-error.log")
}

seems like

standardOutput

and

errorOutput

are causing the problem here. Specifically:

cannot serialize object of type `java.io.FileOutputStream`, a subtype of `java.io.OutputStream`, as these are not supported with the configuration cache. Only `System.out` or `System.err` can be used there.

I can’t use

System.out

or

System.err

as I want to write on file.

Hey guys, I'm curious about the configuration cache behaviour. These are the steps happen: 1. Configuration phase 2. Storing in CC 3. Loading from CC This happen when there is no CC or something changed. I just ask myself if its necessary to load the cache, after it has been stored... Its actually "not a big deal", but for me it just feels strange that it loads again. Everything should be already there/in memory, otherwise it couldn't have been saved, right? 😁 So out of curiosity, is this "needed" to behave like that? Or could this be improved?

Your project is configured with Android NDK 26.3.11579264, but the following plugin(s) depend on a different Android NDK version: - installed_apps requires Android NDK 27.0.12077973 Fix this issue by using the highest Android NDK version (they are backward compatible). Add the following to /Users/nadinjoma/StudioProjects/parental_control_app/android/app/build.gradle.kts: android { ndkVersion = "27.0.12077973" ... } lib/main.dart469: Error: No named parameter with the name 'excludeSystemApps'. excludeSystemApps: true, ^^^^^^^^^^^^^^^^^ ../../.pub-cache/hosted/pub.dev/installed_apps-1.6.0/lib/installed_apps.dart1632: Context: Found this candidate, but the arguments don't match. static Future<List<AppInfo>> getInstalledApps([ ^^^^^^^^^^^^^^^^ Target kernel_snapshot_program failed: Exception FAILURE: Build failed with an exception. * What went wrong: Execution failed for task 'appcompileFlutterBuildDebug'.

Process 'command '/Users/nadinjoma/development/flutter/bin/flutter'' finished with non-zero exit value 1

* 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.

BUILD FAILED in 1m 30s Running Gradle task 'assembleDebug'... 91.5s Error: Gradle task assembleDebug failed with exit code 1. any help??

Hi folks. My environment has dozens of JUnit 3 suite classes - we typically invoke one suite per CI runner - and these are invoked in a proprietary way i.e. not using Gradle. Now I'm registering dozens of

Test

tasks (one per suite) but am finding the need to have a custom "label" for each task . For example, labeling them one of [red, green, blue]. I was considering using

ext

to set a custom property, i.e.

task.ext.color = 'blue'

, or I could register a custom extension type. Are either of these approaches going to break configuration caching? Will querying the extension at build-time cause the task to be eagerly created? In pseudocode, I might have a CI trigger which runs something like:

tasks.withType(Test).collect {
  it.hasExtension(MyCustomColorExtension) and
  it.color == 'blue'
}...

This would enumerate the subset of tasks I need to pass to another downstream system.

I'm trying to enable the configuration cache on one of our project, but I get the following error within the Kotlin Compile task Is there anything I may try?

i am trying to run my flutter program and i have java 17 it shows this error can anyone help please

Launching lib\main.dart on Android SDK built for x86 in debug mode... Support for Android x86 targets will be removed in the next stable release after 3.27. See https://github.com/flutter/flutter/issues/157543 for details. FAILURE: Build failed with an exception. * What went wrong: A problem occurred configuring root project 'android'.

Could not resolve all files for configuration ':classpath'.

> Could not find com.android.tools.buildG 8.0.0. Searched in the following locations: - https://dl.google.com/dl/android/maven2/com/android/tools/build/gradle/ 8.0.0/gradle- 8.0.0.pom - https://repo.maven.apache.org/maven2/com/android/tools/build/gradle/ 8.0.0/gradle- 8.0.0.pom Required by: project : * 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 BUILD FAILED in 6m 41s Error: Gradle task assembleDebug failed with exit code 1 Exited (1).

Hi all I'm trying to enable configuration cache for my project. I'm running

./gradlew assemble --configuration-cache

First run

Calculating task graph as no cached configuration is available for tasks: assemble
[Build log]
Configuration cache entry stored.

Second run

Calculating task graph as configuration cache cannot be reused because the file system entry 'build/classes/java/main' has been created.
[Build log]
Configuration cache entry stored.

Third run

Reusing configuration cache.
[Build log]
Configuration cache entry reused.

How can I debug what depends on

build/classes/java/main

? I'm using

plugins {
    id 'java'
    id "org.springframework.boot" version "3.4.5"
    id "io.spring.dependency-management" version "1.1.7"
    id "org.openapi.generator" version "7.13.0"
    id "org.sonarqube" version "6.1.0.5360"
    id 'jacoco'
    id "io.freefair.lombok" version "8.13.1"
}

and gradle 8.14.

Is there a configuration-cache compatible way of doing the following: Taking a list of configuration (ConfigurationContainer, NamedDomainObjectCollection) and turn them into an input to a task? For example calling

.map { it.incoming.resolutionResult.root }

causes us to realize/create each configuration? So even if the output of this is cc-compatible, it still causes us to realized the collection. Is this fine if it's done in a configureEach, as it'll only be realized if the task is actually called? It just seems like unlike Property/Provider, there's no map/flatMap for the named object collections.

<!channel> if you are interested in knowing more about Configuration Cache, what's coming up in Gradle 9 and beyond, and how to adopt Configuration cache in your builds and plugins... join us for the webinar with @Alex Semin tomorrow! https://gradle.com/events/gradle-configuration-cache-05-25/ We will also use this channel for Q&A, and you are welcome to start adding questions for Alex and the Configuration team below! We will answer everything either asynchronously or during the call

Do not hesitate to ask questions here, we will ask Alex. I am also capturing questions so that we can incorporate them in our docs

And a micro-survey for those who are watching or using Configuration Cache - https://app.sli.do/event/4dkRGVpaxiLiadtgrCj3za

A meeting ran long and I missed the first two third of the webinar. Will a recording be shared?

This message was deleted.

FYI CC issue in Gradle 9 and Kotlin Multiplatform https://kotlinlang.slack.com/archives/C19FD9681/p1748577543128899?thread_ts=1748362393.256609&amp;cid=C19FD9681

We’re looking at enabling Configuration Cache across our company (1000+ devs, 1000s of Gradle based repos, 100s of plugins). It’s quite a mammoth task at this scale, so we want to try and do this incrementally - ie enable it for one workflow like compilation, then work up to running tests, then all the other tasks. This avoids us spending years rewriting all our plugins before we get any value. Has anyone worked out a way to incrementally enable Configuration Cache? Our original plan was: 1. Get our plugins in shape so that compilation (

classes testClasses

etc) fully works 2. Enable CC using gradle properties _in warn mode_ on repos so that CC will work for compilation, just not save the cache state for everything other set of tasks 3. In each repo, specify the max number of allowed CC problems to be the current number of problems. Use this max number of problems as a ratchet to stop people adding new problems (ie stop the bleeding). 4. Automatically reduce this max allowed number of CC problems down as we fix issues 5. CC just works on workflows where everything is fixed 6. Eventually we work down to 0 issues on the whole

./gradlew build

and we hard enforce configuration cache on that repo However, this doesn’t work, as

warn

mode doesn’t do what we expect.

warn

mode is apparently only supposed to be used for diagnosing initial problems. If you use

warn

mode, the build will still go wrong or error on configuration cache issues:

We don’t recommend using

problems=warn

for anything but initial configuration cache adoption attempts to see more issues at once.

From the Gradle team here

With

problems=warn

, it is expected that your build might run incorrectly if there are problems detected.

From here This has kind of stopped us in our tracks, as we can’t just always run in warn mode for all our repos and keep track of the problems. Is there any way to gradually enable configuration cache? Our options seem to be: • Hard enforce CC on each repo using the gradle property. However, this requires getting to completely fixed in each repo in all the plugins and workflows it uses. This will take us a very long time due to the scale of our Gradle plugins (built over the last 13 years - many are quite crusty). • Have our devs opt-in to CC by manually using

--configuration-cache

. This feels like a non-starter to me. Devs shouldn’t have to worry about this and won’t necessarily know which tasks are CC supported or not. It doesn’t enable it in IntelliJ without another IntelliJ Plugin. We can’t stop CC problems from regressing. Is there some other approach?

I'm encountering ``cannot be reused because an input to unknown location has changed` and I wanted to debug it. How can I compare the inputs of the two configuration cache entries? Looks like someone was able to do it here: https://github.com/gradle/gradle/issues/25469#issuecomment-2614299897

It is sad

org.gradle.api.tasks.diagnostics.internal.ConfigurationDetails

is not publicly-available. Any third-party task like

dependencies

would effectively duplicate

ConfigurationDetails

to support the configuration cache. Is there a possibility to make

ConfigurationDetails

public? I would assume it could be a feature-reduced variation of

Configuration

.

Can I somehow fetch

ResolvedArtifact

(coordinates + file) from a

Configuration

so it is compatible with configuration cache? I see I can pass

incoming.resolutionResult.rootComponent

(which is

Provider<ResolvedComponentResult>

) as a task property, however, I do not see how could I fetch artifact file location from the

ResolvedComponentResult

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. 😕