I have a task that has 1 output folder with nested folders. I "publish" 1 nested folder via a consumable configuration, but I cannot use

outgoing.artifact(taskProvider. flatMap { it.outputFolder.dir("nested") })

because the PublishedArtifact tries to run the task during CC time to get the artifact name/file etc. Do I really need to copy the nested files first via an extra task?

Something interesting to try https://bb.staticvar.dev

I’m having trouble with Gradle builds inside Xcode Cloud, with errors that look like this (the exact resolve that fails changes between runs)

> Could not resolve org.jetbrains.kotlin:kotlin-serialization-compiler-plugin-embeddable:2.3.21.
            > Could not get resource '<https://repo.maven.apache.org/maven2/org/jetbrains/kotlin/kotlin-serialization-compiler-plugin-embeddable/2.3.21/kotlin-serialization-compiler-plugin-embeddable-2.3.21.pom>'.
               > Could not GET '<https://repo.maven.apache.org/maven2/org/jetbrains/kotlin/kotlin-serialization-compiler-plugin-embeddable/2.3.21/kotlin-serialization-compiler-plugin-embeddable-2.3.21.pom>'.
                  > Got socket exception during request. It might be caused by SSL misconfiguration

The only workaround that I’ve been able to find is adding these gradle properties (which make the build very slow)

systemProp.java.net.preferIPv4Stack=true
systemProp.java.net.preferIPv6Addresses=false
org.gradle.parallel=false
org.gradle.workers.max=1

I’ve tried: • Setting up a Maven Central proxy in Google Cloud with Google Artifact Registry. Same error occurs (with a different URL) when using the proxy. My original theory was Maven Central rate limiting Xcode Cloud IPs, but I don’t think that’s it. • Changing Java versions (17, 21, 25). Makes no difference. • Checking out open source projects and just compiling them. Now in Android ./gradlew assemble succeeds. Ktor ./gradlew assemble fails. Ktor is a much larger project, which hints that number of requests is related to triggering the issue. In any case, this eliminates something specific to my project. Does anyone have ideas on how to troubleshoot this further?

Any one used 'com.bmuschko.cargo' plugin? I want to know how to use configHomeDir for this in cargo block. As I am getting error ' The <mkdir> type doesn't support nested text data ("C:\wfm\G...tomcat9x").' I didn;t get enough info here https://github.com/bmuschko/gradle-cargo-plugin

I have what I'm going to call a Gradle puzzler for everyone (Gradle 9.4.1 - but I don't think it matters):

$ cat build.gradle.kts
plugins {
    java
}

configurations {
    runtimeClasspath {
        resolutionStrategy.activateDependencyLocking()
    }
}

repositories {
    mavenCentral()
}

dependencies {
    implementation("org.slf4j:slf4j-api:2.0.17")
}
$ cat gradle.lockfile
# This is a Gradle generated file for dependency locking.
# Manual edits can break the build and are not advised.
# This file is expected to be part of source control.
org.slf4j:slf4j-api:2.0.16=runtimeClasspath
empty=

Can anyone tell me what the lockfile should look like after running:

./gradlew dependencies --update-locks com.example:missing

Edit: this is really just a roundabout way of saying

--update-locks

is broken

I'm having difficulties getting the

registerFeature

to work as expected with the distribution plugin. The goal is to create a distribution that contains the functional tests of my app. For each module of my app I have

java {
    registerFeature("funTest") {
        usingSourceSet(sourceSets["funTest"])
    }
}

to register functional tests as a feature. Then in the project that creates the distribution, I have

val Project.hasFunTests
    // Do not dig into sourceSets to avoid coupling between projects.
    get() = projectDir.resolve("src/funTest").isDirectory

dependencies {
    rootProject.subprojects.filter { it.hasFunTests }.forEach {
        implementation(project(it.path)) {
            capabilities {
                // Note that this uses kebab-case although "registerFeature()" uses camelCase, see
                // <https://github.com/gradle/gradle/issues/31362>.
                @Suppress("UnstableApiUsage")
                requireFeature("fun-test")
            }
        }
    }
}

Now, when running the

installDist

task, there are not only

*.jar

files in the

lib

directory as expected, but also a bunch of loose files, like

*.class

files and resources. Although there already are JARs containing these files as well. Am I doing somethign wrong, or might this be a bug with the experimental

registerFeature

/

usingSourceSet

?

Anyone else running into problems upgrading to SLF4J 2.0.18 as

gradle-tooling-api

apparent strictly depends on version 2.0.17?

A problem occurred configuring project ':shared:plugin-info'.
> Could not resolve all artifacts for configuration ':shared:plugin-info:detachedConfiguration3'.
   > Could not resolve org.slf4j:slf4j-api:2.0.18.
     Required by:
         project ':shared:plugin-info' > project :shared:package-curation-providers
         project ':shared:plugin-info' > project :shared:reporters
      > Cannot find a version of 'org.slf4j:slf4j-api' that satisfies the version constraints:
           Dependency path: 'root' (detachedConfiguration3) --> 'project :shared:package-curation-providers' (runtimeElements) --> 'org.slf4j:slf4j-api:2.0.18'
           Dependency path: 'root' (detachedConfiguration3) --> 'project :shared:reporters' (runtimeElements) --> 'org.slf4j:slf4j-api:2.0.18'
           Dependency path: 'root' (detachedConfiguration3) --> 'org.ossreviewtoolkit.plugins:package-managers:87.0.0' (runtimeElements) --> 'org.ossreviewtoolkit.plugins.packagemanagers:gradle-package-manager:87.0.0' (runtimeElements) --> 'org.gradle:gradle-tooling-api:9.5.1' (shadedRuntimeElements) --> 'org.slf4j:slf4j-api:{strictly 2.0.17}'

hi, I want to share a gradle task in a bunch of separate local repositories, specifically • copy various files into a zip (modifying a couple files beforehand) • push a new git tag • create and upload release zip on github • register new release through a REST API I've already achieved that by having a task that changes the files, a zip task that depends on said task and a task that pushes and uploads the release; Questions: • I'd like to have all of that together in one task; is that a good idea? How do I reuse the zip task in my own plugin • What's the best way to distribute that task locally? Is the way forward to mvn install? Missing the steps in between I guess?

how do I use the project version inside a task so that the task gets updated once the project version changes?

can I pass lambdas as task inputs?

how does @Optional work when using Kotlin? is the Property null? doesn't look like I can specify a Property<String?> since Property requires non nullable types

I've got a configuration json file that contains the repository url; is there a way to make that variable accessible to other tasks when the plugin is applied?

In gradle you can run test for all subprojects of your current submodule simply by being in the subdirectory. So running asub atest would run if you're in the suba directory and you run test. Is there a way to get that to work across multiple subprojects? Like if you have :a and 😛 and you want to recursively run build for those, but you also have :c that you want to avoid.

What's the recommended way to deal with credentials like API keys that are required for tasks? passed as properties? env variables? read from stdlin? gradle properties in home? some other way? Asking because most of these seem like bad ideas after the recent NPM supply chain attacks and reading from stdlin feels bad when you need more than 1 token

What would the best understanding bottle necks of the tasks without Develocity. Scan, check biggest times and reason?

Hi 👋 I'd like to verify my understanding of how runtimeClasspath relates to what actually ships to production, since we use it as the basis for our vulnerability-patching routines. Our setup We have a Kotlin/Ktor backend built with Gradle, using the application plugin. Dockerfile:

FROM <jre-base-image>
COPY build/install/*/lib /lib
ENTRYPOINT ["java", "-cp", "/lib/*", "no.example.ApplicationKt"]

CI runs

./gradlew installDist

(among other tasks), which produces build/install/project-name/lib/ containing all jars that end up on the runtime classpath in the container. Our assumption When we audit dependencies for CVEs and decide what to pin via resolutionStrategy, we only care about what actually runs in production. We therefore use: ./gradlew dependencies --configuration runtimeClasspath | grep package Our reasoning: 1. The application plugin's installDist task copies the main source set's runtime classpath into build/install/name/lib/. 2. Other configurations (compileClasspath, testCompileClasspath, testRuntimeClasspath) are irrelevant for the deployed artifact — they may contain dependencies (e.g. transitive deps of test libraries like Testcontainers, Kotest extensions, etc.) that never reach the container. 3. Pinning versions for test-only transitive dependencies in resolutionStrategy adds noise to the build script and gives a false sense of security without affecting production risk. We verified this empirically: jars in build/install/name/lib/ match the contents of runtimeClasspath exactly (main source set's own jar + all resolved runtime dependencies), and test-only dependencies are not present. Questions 1. Is runtimeClasspath (the main source set's runtime classpath) the correct and canonical configuration to inspect when answering "what gets deployed to production" for an application-plugin + installDist + Docker setup? 2. Are there any edge cases where installDist/distTar/distZip would include jars not in runtimeClasspath, or exclude jars from runtimeClasspath? (e.g. configurations like runtimeOnly, developmentOnly, custom dependencies added to applicationDistribution, etc.) 3. Is there a more idiomatic Gradle command we should be using to answer this question — for example, inspecting the actual output of installDist directly, or some configuration like mainRuntimeClasspath that I'm not aware of? Any clarification or pointers to authoritative documentation would be appreciated. Thanks!

1. Is runtimeClasspath (the main source set's runtime classpath) the correct and canonical configuration to inspect when answering "what gets deployed to production" for an application-plugin + installDist + Docker setup?

Actually, that's hard to say generically. Any plugin you apply or any build script can change the configuration of what is actually deployed. But in a plain standard setup, you are right that

runtimeClasspath

is, what is used by the application plugin by default. You should though probably not parse the

dependencies

task output, it's not really made for parsing, but human consumption.

2. Are there any edge cases where installDist/distTar/distZip would include jars not in runtimeClasspath, or exclude jars from runtimeClasspath? (e.g. configurations like runtimeOnly, developmentOnly, custom dependencies added to applicationDistribution, etc.)

Yes, possible.l, depending on the plugins you apply and the configuration you do.

3. Is there a more idiomatic Gradle command we should be using to answer this question — for example, inspecting the actual output of installDist directly, or some configuration like mainRuntimeClasspath that I'm not aware of?

Really heavily depends on your build. You could theoretically also configure

installDist

,

distZip

, and

distTar

differently, even though by default they all use then main distribution copy spec. So if this is high security relevant, you might want to compare the actual packed files with the resolved dependencies or something. 🤷‍♂️

For quite some time now we are struggling to update our Android project to Gradle 9.x.x because on IDE sync we are faced with this failure (complete stacktrace on 🧵 ) :

* What went wrong:
Invalid version string: unspecified
> Invalid version string: unspecified

From the stacktrace I can tell that it has nothing to do with our project. The references are only on IntellijIDEA's model actions (

GradleModelFetchAction

) & Gradle server. How do I even start debugging this? Where & what do I look for in the Android project that might be causing this? I'm asking because many other pet-projects which are using Gradle 9.x.x never failed with this error.

I want to add an exclusiveContent block (i.e. content filtering) to my repository declarations in settings.gradle.kts my issue is that I have a private maven repo declaration and a private maven snapshot repo. my snapshot artifacts keep checking my "regular" maven repo (non snapshot). whats the best way to do that. claude keeps writing extravagent regexs across multiple rules. surely this sort of snapshot vs non-snapshot is a common use case?

Is doing file io (

File.exists()

) fine at configuration time?

Hello, I'm writing a toolchain resolver plugin and I noticed the

JavaToolchainResolver

is a Gradle

BuildService

and I'm wondering if it is possible to inject additional dependencies via constructor and

@Inject

. I'm registering the dependencies via

settings.gradle.sharedServices

however it seems that the resolver class cannot determine those dependencies due to

Unable to determine constructor argument #1: missing parameter of type MyService

In my plugin::apply I'm doing the following

val serviceRegistry = (target as SettingsInternal).services
val toolchainResolverRegistry = serviceRegistry.get(JavaToolchainResolverRegistry::class.java)
toolchainResolverRegistry.register(MyResolver::class.java)

target.gradle.sharedServices.registerIfAbsent("myService", MyService::class.java)

anyone know of any official/unofficial gradle skills/lint checks? seems like some of the android cli skill stuff is pretty nice at picking up mistakes in certain setups, and it seems like gradle would be ripe for making sure best practices are being applied.

if I am adding an experimental/alpha feature to my plugin, would it make sense to add the

@org.gradle.api.Incubating

annotation, or should I use my own annotation type?

Is there a simpler way to do the first thing, or do I have to configure it like that, at the task level? In contrast to the (different) thing below it

tasks.withType<JavaCompile>().configureEach {
    options.release = 11
}

java {
    sourceCompatibility = JavaVersion.VERSION_11
    targetCompatibility = JavaVersion.VERSION_11
}

How do people get the Gradle caches, especially the

transforms

cache, under control? This regularly sucks away gigabytes of disk space with duplicated entries and has to be manually cleaned. I know that things (like for the DSL accessors) are stored by (hashed) classpath and I know Gradle tries to be rather fast and correct than memory-saving, but this situation is becoming unbearable. Once or twice a week I'm dealing with removing things from my 512G SSD just to keep things running.

are declarative gradle and google's lightbuild competitors?

Hey folks, we're seeing a lot of timeouts and HTTP 504 (Gateway Timeout) errors in GitHub Actions when the Gradle wrapper is trying to download the Gradle archives. Is this a known incident?

```Run ./gradlew check --no-daemon

Fetching distribution.

Downloading https://services.gradle.org/distributions/gradle-9.5.1-bin.zip

Attempt 1/1 failed. Reason: Downloading from https://services.gradle.org/distributions/gradle-9.5.1-bin.zip failed: timeout (10000ms)

Error: Exception in thread "main" java.io.IOException: Downloading from https://services.gradle.org/distributions/gradle-9.5.1-bin.zip failed: timeout (10000ms)```

Hello guys, is there native solution to write down metadata related to gradle module? I mean name, description but also responsible person/team, architecture flag (ui,domain,infrastructure), and a few another custom meta information? In the best way it should be exportable to html, md, something readable for non-developer. I found ProjectDescriptor only but it holds only name, description. thanks for replays

Hey I need help. 😃 I thought I had done something similar before, but I can't figure out the following and it drives me nuts. I want to extract the

configurations.runtimeClasspath

into a folder structure, where the contents of each Jar file goes into a separate folder. How do I do that?

tasks.register<Copy>("t") {
    into("libs") {
        from(configurations.runtimeClasspath.map {
            it.elements.map {
                it.map {
                    val folderName = it.asFile.nameWithoutExtension
                    // how can I 'into(folderName)' or 'eachFile { path = "$folderName/path" }' or something like that?
                    copySpec {
                        from(zipTree(it))
                    }
                }
            }
        })
    }
}

Hi team! I am Ricardo from Philippines. As a Senior Full Stack Engineer, I want to contribute to your team.