I have two configurations extending one another. How do you make sure the sub-configuration actually takes the exact same files as the super-configuration's, instead of going off and resolving completely different variants on its own?

having trouble for the first time while building my bundle with the key hash discrepancy my gradle.properties file stores the key pass and keystore pass, and when I build, it wants to escape the characters in my password... any solutions, what other info would be needed to help if so?

I have a

MapProperty<String, List<Object>>

in my plugin extension. I need another plugin to merge items into the map instead of overwriting it like

put

does. I thought this would work:

extMap.putAll(extMap.map { m ->
   m.keys.forEach { k ->
      m.merge(k, myValues(), { l1, l2 -> l1 + l2 })
   }
   return@map m
})

but instead it causes a stack overflow error due to the value depending on itself. I also can't add elements in

Project.afterEvaluate

because

MapProperty#get

returns an ImmutableMap. How do I add items to the lists in the map?

This is a question about the java-platform plugin (or really, just about dependency constraints), and how that interacts or doesn't with variants. for Gradle projects with test fixtures (more generally: additional variants), do we need to declare the constraint multiple times?

Hey everyone. We've just migrated our Android team's git repos to a monorepo with the Gradle build system at its root. It consists of 3 large apps and multiple small libraries (150k lines of code in total). The issue is that devs are getting lots of performance issues when opening the monorepo in the Android studio regarding build time and indexing (find usages, navigating in the project, ...). What have we potentially done wrong in the process of migration and what are the solutions for this type of isses?

... what happened to the great propertization ... v9 appears to have fixed zero of my "I need this to be lazy" issues, publishing still appears to be eager, version is eager... checkstyle still compiles java (even though checkstyle itself doesn't need that)

Has someone seen this crash after upgrading to Gradle v9? The full stacktrace does not point to any code I own in my convention plugins 🤔

* What went wrong:
A problem occurred configuring project ':semver-gradle-plugin'.
> Failed to notify project evaluation listener.
   > Cannot mutate the hierarchy of configuration ':semver-gradle-plugin:apiElements' after the configuration was published as a variant. After a configuration has been observed, it should not be modified.
   > Gradle Module Metadata can't be modified after an eagerly populated publication.

Hello!

dependencyProject

is deprecated but on the deprecation it is not shown any alternative 🤔

Hello!

What is the solution to this error?

``````

Hi everyone 🤗 Our Gradle project has slowly become a mess. An actual ball of spaghetti. Projects depending on projects everywhere with deep paths from our app project to our lowest level project. I tried using a plugin such as this one Graph Assert (https://github.com/jraska/modules-graph-assert) to understand the scale of the problem (it's big) but am struggling to figure out some proper next steps. The goal would be to improve build speeds and enforce a better Gradle graph health going forward. Has anyone faced similar challenges? And would they be able to offer some concrete suggestions for how to plan our way out of this? The project is about 130 modules (Android and Kotlin with some legacy Java) at the moment and takes about 25 minutes to compile on the CI. That's before we start running tests. For example what are some useful things to measure and how? Or what is a repeatable process for refactoring that we can farm it to the entire team including junior engineers that is easy to understand and fool proof? Cheers

How do I check if a task exists? I tried

tasks.named(...).isPresent

, but it seems tasks.named is throwing an UnknownTaskException instead?

Also, with project.exec deprecated, is the recommended approach to do

project.providers.exec { ... }.result.get()

?

Getting this error classpath inside javaexec: classpath Exception in thread "main" io.cucumber.core.gherkin.FeatureParserException:

Upgrading from 8.14.3 to 9.0.0, now my Github Actions fail, encountering:

Class org.gradle.jvm.toolchain.JvmVendorSpec does not have member field 'org.gradle.jvm.toolchain.JvmVendorSpec IBM_SEMERU'

What am I running into? In

build.gradle

I have declared:

java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(24)
        vendor = JvmVendorSpec.GRAAL_VM
    }
}

Is there a flag I can pass to gradle to tell me why a given task is not UP-TO-DATE when it should be?

you can either use build scans or run with info logging (using -i) which usually logs why its not considered up to date. but be aware gradle logs a lot already with -i

I am using gradle8.8 with java21.Passing an option value to custom doclet .like this options.addStringOption('outputdir','output') but when I run the task doclet is giving an error.error: invalid flag: -d 1 error Usage: javadoc [options] [packagenames] [sourcefiles] [@files] Is this a known error? the same works when I execute the doclet from terminal.

Hey guys, I recently activated Configuration Cache in my project. Everything works fine, except when executing

./gradlew :app:dependencies

I receive the following exception:

Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "pool-1-thread-1"

Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "main"

I am using

org.gradle.jvmargs=-Xmx10240m

and also increasing it to 12 GB didn't help. All the other tasks just run fine, e.g. building, testing etc. - the activated configuration cache is on develop for a few days now already. Does anyone have an idea what could cause the OOM on the dependencies task and how to fix it? Deactivating the configuration cache fixes it but should not be an option here 😄

I'm seeing failing CI builds recently, and it seems that Gradle Plugin Portal is hanging up on us. Is there an active incident there right now?

> Could not resolve com.google.cloud.tools:jib-gradle-plugin:3.4.5.
  Required by:
      settings file 'settings.gradle' > com.google.cloud.tools.jib:com.google.cloud.tools.jib.gradle.plugin:3.4.5
   > Could not resolve com.google.cloud.tools:jib-gradle-plugin:3.4.5.
      > Could not get resource '<https://plugins.gradle.org/m2/com/google/cloud/tools/jib-gradle-plugin/3.4.5/jib-gradle-plugin-3.4.5.pom>'.
         > Could not GET '<https://plugins-artifacts.gradle.org/com.google.cloud.tools/jib-gradle-plugin/3.4.5/760ae3b530620eea5483f15fe876fd30ac44e5dcb7eafca4d63e613ea0d80750/jib-gradle-plugin-3.4.5.pom>'.
            > Remote host terminated the handshake

The

Sync

task deletes all files in the target directory, and then copies the new ones over. Is it possible to configure

Sync

(or some other task) to NOT touch the files that haven't changed? I'm using another tool afterwards, which reacts to the files being deleted, even though they are immediately recreated identically.

How can you sync Gradle with IntelliJ when verifying the signatures? Can you enable verification via a property? Currently I can't sync because IntelliJ tries to download the sources.jar via a detachedConfiguration (added via init script).

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.