I saw an (old) post on the Gradle community that stated plugin version resolution functioned with 'latest.release' or the other notations to always provide latest like '1.+', etc. since Gradle 7.x I am seeing this is not working properly in my build environment with Gradle v9.1.0, but I am unable to see what version of a plugin is actually resolved, with gradlew --info, I only see '1.+' was resolved, but not the specific version that was selected. gradlew dependencies doesn't show the plugins dependency tree -- is there a command that will show the specific plugin versions selected for a build?

When creating a feature variant using the groovy DSL. How would I make test depend on my feature variant? I did a Google and I found and answer but I guess I want to make sure I'm using configurations properly given the unfortunate potential for unlazy API usage in my opinion. Also if there's any way to avoid four extendsfrom minimum... And is there any way to extend from platforms that would have been defined there? At least I hope they were defined as platforms

https://github.com/avast/gradle-docker-compose-plugin/issues/486 Any insights into whether the problem is with the plugin or Gradle's configuration cache? Slightly lean towards plugin (although it should support the configuration cache), but the error message makes me wonder. There's also some weird behavior where the issue doesn't repro if you build first with the cache disabled, but then build the exact same code with the cache enabled.

Execution failed for task ':app:test'.
> Cannot cast object 'org.gradle.internal.serialize.codecs.core.ClosureCodec$BrokenObject@46f481e2' with class 'org.gradle.internal.serialize.codecs.core.ClosureCodec$BrokenObject' to class 'com.avast.gradle.dockercompose.TasksConfigurator'

The issue includes a fairly simple MCVE.

Wondering how to overwrite duplicate files while bunding the war. Not finding any overwrite duplicate strategy in documentation. If i use EXCLUDE strategy, its keeping only the first file and ignoring my 2nd file file. If i use INCLUDE strategy, its keeping both files in war but i need to keep only the 2nd file. and rest of the options(FAIL, WARN, INHERIT) will not help in this case. Hope am not the first one facing this challenge.

https://gradle-community.slack.com/archives/CA7UM03V3/p1760124221741589 My company used to checkin the gradle revision to our github repository. Gradle would be part of our CircleCI github download, i.e. our bandwidth cost. That was gradle 6.0.1. We moved to gradle 8.x. The download zip exceeded 100M. It is too large for a standard checkin. Now each of our CircleCI builds downloads gradle 8.11 against gradle's bandwidth cost, not ours. I suggest this might be a cost problem/opportunity to gradle.org.

I'm unfortunately working on a project where i have to migrate some legacy definition blocks to the modern way this is what ive got left

buildscript {
   // this is all I have left to migrate
    ext.kotlin_version = '1.9.24'
    dependencies {
        classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version"
        classpath "org.jetbrains.kotlin:kotlin-serialization:$kotlin_version"
        classpath 'com.android.tools.build:gradle:8.10.1'
        classpath 'com.jakewharton:butterknife-gradle-plugin:10.2.3'
        classpath "org.jacoco:org.jacoco.core:0.8.13"
    }
}

it seems like theres no way to just migrate to new plugins block directly... instead you have to lookup the documentation for each plugin. am i correct in my understanding? and what do i do if a plugin doesn't publish how to use the new plugins block (like butterknife)?

After upgrading from Gradle 8.11.1 -> 9.0.0 some UTF-8 characters in html are not rendering properly. The following two images is one example of what a before-and-after picture looks like.

The only change is the gradle wrapper version used to build the jar.

👋 Hello, team!

I want my convention plugins to notify users that they should have applied the plugin that convention plugin is for explicitly (if they only applied convention plugin without plugin to configure) Previously I relied on

afterEvaluate

but since this discussion about just how much of a legacy approach

afterEvaluate

is, I have been looking for a good solution for this. Would

BuildService

with

FinishEventListener

that throws if plugins were not applied be an idiomatic approach?

What is the Dataflow Actions docs section Using lifecycle event providers supposed to be demonstrating? A BuildWorkResult doesn't contain

buildInvocationId

,

workspaceId

, or

userId

- just

getFailure()

.

Keep having this issue, can someone tell me a way to fix it, ive tried multiple diffrent things: * What went wrong: Execution failed for task 'appcleanMergeDebugAssets'.

java.io.IOException: Unable to delete directory 'C:\Users\scott\Documents\ClearEntry

I have a list of legacy plugins I am working with at the moment, some of these have code like this

project.rootProject.subprojects {
    tasks.withType(org.jetbrains.kotlin.gradle.tasks.KotlinCompile::class.java) {
        compilerOptions {
            freeCompilerArgs.add("-Xsam-conversions=class")
        }
    }
}

From what I could look up it seems this behaviour should be now enabled by default but Gradle documentation still mentions this https://docs.gradle.org/current/userguide/kotlin_dsl.html#sec:kotlin_compiler_arguments What am I missing?

Is anyone aware of a good way / Gradle plugin to measure peak memory usage when running functional tests via the CLI?

How do I create an aggregator tasks such that it collects all

detektMain

tasks, but from within a current project's (

app-a

) dependency graph (not globally; I have multiple apps in the total build)

tasks.register("detektAllDebug") {
        group = "verification"
        def projects = collectDependencyProjects(project(":foo:app"))
        def tasks = collectTasks(projects, "detektMain")
        tasks += "detektMockFakeFaceRecoFakeEsimStableDebug"
        tasks += "detektMockRealFaceRecoRealEsimStableDebug"

        dependsOn tasks
    }

I have something like this

static Set<Project> collectDependencyProjects(project) {
    def collectedProjects = [].toSet()
    doCollectDependencyProjects(collectedProjects, project)
    collectedProjects.remove(project) // Remove root
    return collectedProjects
}

static void doCollectDependencyProjects(collectedProjects, project) {
    if (collectedProjects.contains(project)) return

    collectedProjects.add(project)

    def subProjects = project.getConfigurations()
            .inject([]) { acc, config -> // Accumulate all
                def configName = config.getName()
                // Ignore test projects
                if (configName != "testImplementation" && configName != "testApi") {
                    def dependencies = config.dependencies.withType(ProjectDependency)
                    if (dependencies.size() > 0) {
                        acc.addAll(dependencies)
                    }
                }
                acc
            }
            .collect { it.getDependencyProject() } // Map

    for (subProject in subProjects) {
        doCollectDependencyProjects(collectedProjects, subProject)
    }
}

static def collectTasks(subprojects, name) {
    def allTasks = []
    for (project in subprojects) {
        def task = project.tasks.findByName(name)
        if (task != null) {
            allTasks += task
        }
    }
    return allTasks
}

where I recurse into the graph and collect Works, but I have feeling there is more gradle-y way

The hyperlink in the document points to an unknown page.

What's the right solution for making verification type tasks cacheable? My task doesn't produce any output as it just checks certain conditions being present in the build? How do I make it cacheable? Do I just make a token output item like a file I write "verification successful" to? Where do I put it then, does this make sense?

layout.buildDirectory.file("intermediates/***/***.txt")

Hello, How can i deploy a zip artifact from within my custom task. For example, i used

FileOperations

class to create the zip archive using the

zipTree

. Can someone please refer or attach a sample on how can i continue the workflow to deploy it on a maven repo

Is there any reason why the configuration cache changes the order in which tasks are executed? The example here involves the

com.avast.gradle.docker-compose

plugin (version

0.17.18

). With the configuration cache disabled, it runs, e.g., in this order:

:lib1:composeUp

,

:lib1:test

,

:lib1:composeDown

,

:lib2:composeUp

,

:liib2:test

,

:lib2:composeDown

. But with the configuration cache enabled, it looks like it runs

:lib1:composeUp

and

:lib2:composeUp

in parallel first. Which can cause issues if there are port conflicts between those two tasks. I've attached an MCVE.

If I add

foo=bar

to my root project

gradle.properties

, how is this working if this same root project becomes an included build? 1. The main build value is used 2. The included build value is used 3. It depends If 3., how can I tell?

Not sure if this is a gradle or kotlin problem ... we have:

testFixturesImplementation("org.apache.commons:commons-lang3")
toolsImplementation("org.apache.commons:commons-lang3")

and that was sufficient to compile our kotlin unit tests. Today, I started the work to upgrade out build setup to use kotlin 2.2.20 (from 1.9.22 before), and now those kotlin unit tests using lang3 don't compile any more.

e: file:///Volumes/Whatever/.../foo/src/testFixtures/kotlin/.../Blub.kt:23:27 Unresolved reference 'lang3'.

(and similarly, another kotlin unit test that relies on src/tools/java ... also doesn't see those classes any more.

Hi all, To try and benefit from build caching, our CI server shares the

~/.gradle/caches/build-cache-1

between runs. Unfortunately this means periodically when two builds run concurrently one fails as so:

> Failed to load cache entry 0801251eccdf893889c1065191e1327d for task ':admin-api:findDeclaredProcsMain': Could not load from local cache: Timeout waiting to lock Build cache (/home/worker/.gradle/caches/build-cache-1). It is currently in use by another process.
  Owner PID: 52
  Our PID: 53
  Owner Operation: 
  Our operation: 
  Lock file: /home/worker/.gradle/caches/build-cache-1/build-cache-1.lock

Looks like it's a 30 second timeout. Is this a sign that sharing that directory is a bad idea? Or that Gradle is being too aggressive with the lock (could it take and release it much more frequently during concurrent builds, I wonder)?

I have a project using Gradle 8, and ran into a build issue recently. The code uses a library with logging implemented with a newer version of slf4j, using method logger.atInfo(), logger.atWarn() etc. This project compiles fine, and the right version of slf4j dependency was downloaded. However the build complained

java.lang.NoSuchMethodError: 'org.slf4j.spi.LoggingEventBuilder org.slf4j.Logger.atInfo()'

on running test, because Gradle automatically adds gradle-api.jar in the class path, and the jar file contains an older version of slf4j API that doesn't have these methods. Is there a way to exclude gradle-api.jar from the class path? The normal way of excluding transient dependency doesn't work, because nothing depends on gradle-api.jar except gradle itself.

I am looking for instructions or an Gradle Kotlin DSL based example project for JNI. I find things like https://www.jetbrains.com/help/idea/setting-up-jni-development-in-gradle-project.html but those are written in Groovy DSL and converting to Kotlin DSL looks non-trivial.

I have

build-logic

included build I use for convention plugins, the type you apply to gradle projects to unify declarations like

android { }

In my gradle scan I get this message

The build cache configuration of the root build differs from the build cache configuration of the early evaluated ':build-logic' included build. It is recommended to keep them consistent, see here.

From what I could look up this is due to the fact I compose my included build inside

pluginManagement { }

instead of directly on the

settings.gradle.kts

itself I guess I have a few questions: 1. Can I include my

build-logic

outside of

pluginManagement { }

? 2. Alternatively I could copy over buildCache configuration to the

build-logic

? What's the right approach? Is using pluginManagement includeBuild() a specific case that should be used only in some situations? Like providing a plugin that targets the

settings.gradle.kts

itself?

how to use shadowJar's output as an artifact when using Composite Build. I have two gradle project A and B, B depends A, and use compisite build to reference A, but A use shadow plugin. when i use

includeBuild('../A') {

dependencySubstitution {

substitute module('me.myname:a') using project(':')

}

}

gradle will awayls use jar task's output

trying to add a specific jar to a version catalog that is currently resolved using this notation:

implementation "com.my-company:my-project:my-version:spec"

I haven't been able to find a way to declare the ':spec' specific jar within the confines of the version catalog -- any ideas?

I thought something wrong with my code, but then found this in gradle sources. Any idea how to fix this red errors? Is it IDEA bug?

In my convention plugins included build I was adding dependencies as

compileOnly

(I think my idea was mainly leaving root module

plugins { }

as a single source of truth for putting plugins on classpath This approach seemed to work just fine until I decided to lift gcp build cache plugin out of

settings.gradle.kts

Now all of the sudden my android library convention plugin fails to resolve classes like com.android.lint How do I make sense of this and what’s the solution? My current intuition is that gcp build cache plugin being applied to settings was maybe putting com.android.library on classpath? Also if I decide to use implementation configuration for convention plugin dependencies does it mean I will need drop root module plugins with apply false and instead have versionless plugins in my build files?

A The whole demon jvm thing. Does the Gradle GitHub action support this? Meaning will it cache one that's been downloaded? I'm assuming I would still need to do a setup jvm in GitHub actions though because I imagine that doing that download requires a jvm in the first place. What happens if the required version is something that you already have? And is Gradle support any sort of that version or later? Since the jvm release can now compile for any version?