tl;dr: Do you have a Gradle build or plugin that would benefit from a fine-grained caching tool? What would you use it for? I've been tinkering with a Kotlin Native project that compiles C code, but DevEx was bad because compilation was really slow, for two main reasons: 1. Any changes to the buildscripts, even if they were unrelated, meant a new build-cache key, which means a long, slow recompile of everything. 2. Build cache was too coarse, and the compile-C task would re-compile everything even if only 1 file out of 1000 changed. Or the changes in the sources were not relevant (like only changing a comment). I kept getting annoyed because any changes in the buildscripts would trigger recompilation of everything, which was really slow. So, I created a custom caching daemon! It supports caching individual operations (e.g. compiling a single file, or creating an archive). The cache key only considers the actual inputs, so it's not sensitive to buildscript changes. Another benefit: the parallelism can be more tightly controlled, no matter how many subprojects/tasks/files there are. It's still messy, but as a POC it's working well in my hobby project. I'm considering splitting it out as a separate library, but before I do I really wanted to get some more information: If I released a per-file caching library as Gradle plugin, how would you use it?

Question: Suppose I am applying a plugin that depends on, transitively, a jar that is marked as vulnerable or outdated, How do I replace it with a version that is current? Would I need to apply dependency constraints (or a platform) on the buildscript classpath, or will it suffice to put dependency constraints on, say, a convention plugin that applies that plugin?

Hi, folks! Quick question: I know about

aProvider.zip(bProvider) { a, b -> MyData(a, b) } // Provider<MyData>

but this is fine for merging two providers. What about when I have more of them? Would this be acceptable from the design perspective?

providerFactory.provider {
    MyData(a.get(), b.get(), c.get(), d.get())
}

Hey all, I have a gradle project with multiple submodules and leveraging buildSrc to have common build logic for the multiple submodules. Now I'm trying to run multiple tasks in parallel to speed up my CICD via background processes like

./gradlew my-task1 &

and then grabbing the process ids and wait on them. The thing is I'm getting the following error

Timeout waiting to lock build logic queue. It is currently in use by another Gradle instance.
Owner PID: 456
Our PID: 512
Owner Operation: 
Our operation: 
Lock file: /home/cicd/.gradle/noVersion/buildLogic.lock

I'm setting

org.gradle.daemon=false

in my

gradle.properties

file, however I believe this might be related with the buildSrc as it is shared and we might not be able to build it concurrently? Is that it? If so any ideias on how to do such Note: I'm not using

--parallel

because im calling same tasks with different values for parameters. Thanks in advance ✌️

Hey! Another Providers-related question: I'm adding lazy dependencies to the configuration, like:

configurations[configurationName].dependencies.addLater(
    myProvider.map { myValue ->
        println("myValue=$myValue")
        return ...
    }
)

And yes, this gets printed 20-30 times when the project is being configured. Is that expected, and I shouldn't interfere with that, or is using a cached provider a good choice here?

Hi all. In Hibernate ORM we're having trouble with compile times, because the incremental compilation is too coarse grained. It looks like this was reported in the past, but unfortunately, there is no link to a GitHub issue where I could track the progress for that. I tried to search for some keywords but couldn't find anything yet. Does anyone of you have an idea if this problem is tracked somewhere?

I'm having trouble taking the Jackson BOM into use. In

settings.gradle.kts

I have

dependencyResolutionManagement {
    @Suppress("UnstableApiUsage")
    repositories {
        mavenCentral()
    }

    versionCatalogs {
        create("libs") {
            from(files("../gradle/libs.versions.toml"))
        }

        create("jackson") {
            from("com.fasterxml.jackson:jackson-bom:2.20.0")
        }
    }
}

which leads to

Could not resolve all artifacts for configuration 'incomingCatalogForJackson0'.
> Could not resolve com.fasterxml.jackson:jackson-bom:2.20.0.
  Required by:
      unknown
   > No matching variant of com.fasterxml.jackson:jackson-bom:2.20.0 was found. The consumer was configured to find attribute 'org.gradle.category' with value 'platform', attribute 'org.gradle.usage' with value 'version-catalog' but:
       - Variant 'compile':
           - Incompatible because this component declares attribute 'org.gradle.category' with value 'library', attribute 'org.gradle.usage' with value 'java-api' and the consumer needed attribute 'org.gradle.category' with value 'platform', attribute 'org.gradle.usage' with value 'version-catalog'
       - Variant 'enforced-platform-compile':
           - Incompatible because this component declares attribute 'org.gradle.category' with value 'enforced-platform', attribute 'org.gradle.usage' with value 'java-api' and the consumer needed attribute 'org.gradle.category' with value 'platform', attribute 'org.gradle.usage' with value 'version-catalog'

What's wrong with my syntax?

Hi there. Seeing an issue with composite builds in intellij since upgrading to gradle 8. My project has both a

buildSrc

project and an "external" build which creates some gradle plugins. It used to be that I could enable Composite Build in the intellij UI, and then it would resolve my plugin classes back to source when navigating from buildscripts (very nice!) ...but, since upgrading to gradle 8, it seems that my

buildSrc

is always listed as a composite, which prevents intellij from showing the option to enable composites (if I enable composites in settings.gradle, the gui option is normally removed, but it also doesn't work properly in IDE). So, does anyone have any ideas or suggests? gpt suggested removing

buildSrc/settings.gradle

but that didn't help, and manually printing the included builds shows nothing. I'll attach the xml I pulled from

.idea/gradle.xml

in a thread, in case it helps.

Hello all! When Gradle recompiles build script files during the configuration phase, then this apparently happens single-threaded, as all the other threads are shown as idling. Is there any plan to make this compilation multi-threaded or maybe I'm just missing a flag to enable this? I'm on Gradle 9.1-rc-1.

Is there anyone here that uses helm in their gradle builds. If so, do you happen to know of a good alternative for https://github.com/Citi/gradle-helm-plugin/? It seems this plugin's development stagnated and unfortunately they're not compatible with gradle 9: https://github.com/Citi/gradle-helm-plugin/issues/126 I'd like to avoid having to fork the project in order to fix the compatibility issues, so any suggestion for an alternative is much appreciated.

Are Gradle developers using IntelliJ for running and debugging tests? My IntelliJ always gets stuck when doing a "Step Over" through the debugger and I'm curious if anyone else had this problem already?

I have a task

tasks.create(name: 'dist', dependsOn:  subprojects.publishInternal) {

Often execute "./gradlew dist". Sometimes execute "./gradlew clean dist". The latter works fine until setting "org.gradle.parallel=true". What is the correct way to say dist must execute after clean if and only if clean is being executed?

what are the implications, if any, of using

ProcessBuilder

(vs

ExecOperations

) during Gradle config? IIRC, configuration cache doesn't know anything about such a process and can't treat it as part of the cache key? Does it "break" CC in any way?

I'm using

withPluginClasspath

when testing my plugin that interfaces with AGP, however AGP is a

compileOnly

dependency in my project. I tried also adding it as a

testImplementation

dependency, but I'm still getting errors like:

> Failed to apply plugin 'com.eygraber.release-tag-version-code'.
   > Could not create plugin of type 'ReleaseTagVersionCodePlugin'.
      > Could not generate a decorated class for type ReleaseTagVersionCodePlugin.
         > com/android/build/gradle/AppPlugin

Changing the AGP dependency to

implementation

makes the test work, but I'd prefer to keep

compileOnly

. Any options?

Hello, I'm new to this slack channel and looking for help in getting things configured I am trying to use an ionic capacitor app and running into issues with JDK versions in gradle. Gradle seems to be convinced that I need JDK 21 and its not there (even though I have JDK 21 installed) but I believe my project needs JDK17. VS Code has never been able to launch the android app. I've had to build, sync, and then go to Android studio to open it. No matter what I do, I can't get android/app/capacitor.build.gradle to show any version other than 21

* What went wrong:

Execution failed for task ':capacitor-android:compileReleaseJavaWithJavac'.

> error: invalid source release: 21

Not sure If I'm posting in the right place or asking the right question, but if anyone could assist it would be greatly appreciated!

Hey all 🙂 we have huge scala/play project with gradle. I know that gradle can give u some build stats for example what was the execution time of each task. Is there a way to get some more low level scala statistics? my hope is maybe to be able to find packages/classes/files that takes more time to compile then others, and see maybe there's a way to refactor and reduce these "problematic" packages/classes/files

I have a question about best practices for loading properties from a custom file. I was thinking that it might be better to move this functionality to the settings.gradle.kts file in a gradle.lifecycle.beforeProject scope, which would be during the initialization phase instead of the configuration phase. This would make it accessible to each project without having to call rootProject (having some weird condition where findProperty isn't finding something in the rootProject from a subproject). But I was thinking this would alleviate any race conditions when moving to Isolated Projects, when they configure in parallel. Is this a better way to load a separate property file? And what impact would this have on performance/caching?

So has anyone ever seen this one before ... I'm trying to test a reproducible build, the project has this code in it: tasks.withType(AbstractArchiveTask).configureEach { preserveFileTimestamps = false // to prevent timestamp mismatches reproducibleFileOrder = true // to keep the same ordering // to avoid platform specific defaults, set the permissions consistently filePermissions { permissions -> permissions.unix(0644) } dirPermissions { permissions -> permissions.unix(0755) } } My sources jar is created with a different ordering of file names when run locally vs in orbstack vs in dockerdesktop ... orbstack & locally are matching. It's only differeing in docker desktop.

Hi! I've been trying to setup a read only dependency cache (https://docs.gradle.org/current/userguide/dependency_caching.html#sec:shared-readonly-cache). Works great, pretty much 99.9% of our network transfer has been cut, and builds are faster. but not quite as fast as I had hoped. Despite having this cache available, it seems like Gradle still performs HEAD requests for each dependency. I'm assuming this is to verify the validity of the cached dependency (hash, size, whatever)? These add up to quite a bit of time. Would there be a flag I could turn on to disable those requests, fully trusting the local cache (and falling back to the network should it not be there)? --offline is a bit too aggressive for my taste, and would rather have a --offline-but-maybe-sometimes-why-not EDIT: solution: don't try to debug performance issues on the build that runs with --refresh-dependencies.

Is there an easy way to tell if a plugin is compatible with the configuration cache? I've been trying to get this plugin (https://mvnrepository.com/artifact/org.springdoc/springdoc-openapi-starter-webmvc-ui) to work, and so far, as soon as I turn on the CC, it fails spectacularly. I have no idea if this is me being stupid (quite likely) or if I'm just out of luck with that plugin.

How would you go rewriting this task so that its arguments take a full

CopySpec

so it's possible to write

from(project.tasks.named(configTask))
		from(project.tasks.named(sourceTask)) {
			into("kotlin")  // ← this
		}

(like is possible with the native

Copy

and

Sync

tasks)?

Is it possible to publish two (or more) variants of a module BUT have one variant specified as some kind of default so that consumers who are blissfully unaware of all this variant business but are using Gradle would select this variant automatically? My understanding is that if the consumers won't have attribute rules configured they would fail due to ambiguous variants, but I would like to avoid that for legacy consumers.

I have an issue with a transitive dependency which is selected by a rule. I don't quite understand why the older dependency is picked.

io.netty:netty-codec-http:4.1.124.Final	
\--- io.netty:netty-codec-http2:4.1.124.Final	
     \--- software.amazon.awssdk:netty-nio-client:2.33.4 (requested io.netty:netty-codec-http2:4.1.126.Final)	
          \--- software.amazon.awssdk:s3:2.33.4	
               \--- runtimeClasspath

So I am getting the latest awssdk:s3, which asks for netty 4.1.126.Final. However gradle chooses to pick jetty 4.1.124.Final instead. I don't have any other dependencies to jetty in the project (transitive or direct). This is the info by dependencyInsight:

io.netty:netty-codec-http:4.1.124.Final (selected by rule)	
  Variant runtime:	
    | Attribute Name                 | Provided     | Requested    |	
    |--------------------------------|--------------|--------------|	
    | org.gradle.status              | release      |              |	
    | org.gradle.category            | library      | library      |	
    | org.gradle.libraryelements     | jar          | jar          |	
    | org.gradle.usage               | java-runtime | java-runtime |	
    | org.gradle.dependency.bundling |              | external     |	
    | org.gradle.jvm.environment     |              | standard-jvm |	
    | org.gradle.jvm.version         |              | 21           |

Can someone explain?

How do I access POM files of dependencies in a configuration? I tried something like the following but got an empty collection:

def files = configurations.myConfig.incoming.artifactView {
            attributes.attribute(ArtifactTypeDefinition.ARTIFACT_TYPE_ATTRIBUTE, "pom")
        }.files.files
        println("Files: $files")

Hey there, I'm trying to autoactivate the buildscan on several conditions e.g. if in CI or if explicitly required on command line. Handling the CI part is easy but I wasn't able to overcome the

--scan

condition, the following code fails

develocity {
    buildScan {
        termsOfUseUrl.set("<https://gradle.com/help/legal-terms-of-use>")
        termsOfUseAgree.set("yes")
        publishing {
            onlyIf {
                (System.getenv("CI") != null) or gradle.startParameter.isBuildScan
            }
        }
    }
}

with a serialization issue

1 problem was found storing the configuration cache.
- Gradle runtime: cannot serialize object of type 'org.gradle.initialization.DefaultSettings', a subtype of 'org.gradle.api.initialization.Settings', as these are not supported with the configuration cache.
  See <https://docs.gradle.org/9.0.0/userguide/configuration_cache_requirements.html#config_cache:requirements:disallowed_types>

Maybe you have more ideas on this ?

To create instances of 'managed' objects Gradle uses ASM to generate subtypes, and additionally creates inner classes to instantiate new instances. The inner classes are marked as 'public' and 'synthetic'. E.g. in NamedObjectInstantiator and a couple of other places. My understanding is inner classes should always be static, where possible, to avoid memory leaks. Should

ACC_PUBLIC | ACC_SYNTHETIC

be replaced with

ACC_PUBLIC | ACC_SYNTHETIC | ACC_STATIC

?

Not sure if anyone faces this, but for folks who publish SDKs to an internal repository using Gradle's maven-publish plugin: When I publish multiple modules with variants from a relatively large repo (~50 artifacts), some publications occasionally fail due to network issues. This causes the entire Gradle task to fail. Rerunning the publish task doesn't work since it retries all variants, and our repository rejects duplicate uploads for the same version. Current options I'm considering: 1. Delete the partial publish and republish everything (current approach) 2. Check what's already published and only publish remaining artifacts 3. Configure automatic retries within the maven-publish plugin (not sure how to implement this) 4. Use Gradle's --continue flag to skip failures Has anyone found better solutions or know how to implement option 3? Any alternative approaches?

Does anybody have tips or tricks when it comes to diagnosing issues of builds failing on ci? We'd like to start tracking issues where daemons dissapear, or are shutdown due to crashing, or crash due to 'user error' (tests failing, compile failing) and other causes of ci flakiness. Are there apis or files we can inspect to validate run results after the fact? Or do we just have to search thru build logs and look for key words?

Will a set of test workers always have strictly monotonic increasing numbers for test workers via the

org.gradle.test.worker

system property?

What should be the direction to reach local gradle build (only for dev purpose and not for publishing) from a medium sized multimodule maven project having parent pom, some standard and some custom plugins, properties and tons of dependencies? What I've tried? Run gradle init on root directory and manually putting 100s of dependencies like

implementation '<sample-dependency>'

in a child module by getting all dependencies from dependency management of root pom.xml. Is there an easy fast way to achieve the end result here? P.S. Other teams dont want to move to gradle and parent pom will also remain in maven, hence want to navigate this situation for my team to get incremental compilation support to a big child module where changing small things leads to recompiling of 10k+ classes. 🙏