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

What's the idiomatic way to configure a task by name if A) it already exists, or B) it's added later, but without crashing if it's not added at all? E.g., with plugins we have

pluginManager.withPlugin

. For tasks, I'm thinking

tasks.matching{ it.name == "sourcesJar" }.configureEach {...}

? Is this lazy enough?

Hi, I am having an issue with my app since I am using VS code to develop it. Basically I am including firebase into my app to avoid pasting documents such as "quotes" directly on my code. When I launch my app with VS Code it says that some firebase dependencies aded on the build.gradle.app folder couldn't be found even though I have all the dependencies, integrations right. I am using Chat GPT for help but the issue still remains. Does anyone have a solution ? (I am beginner btw)

Is there a way in gradle to "link" 2 tasks so that if one runs, the other is always forced to run too? The problem I have is I have a task that configures compileGroovy , so when something triggers compileGroovy to run, I need to make sure my task isn't loaded from cache. I tried depending on the runtimeClasspath - but then any task that changes that task, my task needs to declare a dependency or gradle will fail (complains about an explicit depndency is required). Ideally, I'd use doFirst { } in the groovy compile step, but I can't because it could actually be N+1 tasks that need to run before compileGroovy. Was hoping to avoid just disabling caching on that task - i don't want it to run over and over unless it has to.

How has this issue been around for 5+ years, and never got even a call out in the documentation for

gradleProperty

? Just wasted hours on this 😞 https://github.com/gradle/gradle/issues/23572 https://github.com/gradle/gradle/issues/13302

Sometimes I need to install a cacert into my jdk so that gradle can pull down dependencies for my project. If I try to sync gradle, and it fails... and then i install the cacert... i can't sync gradle again and get a success. instead... I need to delete the global

.gradle

folder on my mac. then sync again. and everything works. Anyone know why that is? deleting

.gradle

is a heavy operation and id love to only delete a specific file or something inside of

.gradle

if anyone knows the true culprit.