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?

I have seen a few times gradle projects split into api/impl but to date I have never seen a good information on this topic. I am talking about module like feature-something being split into

feature-something-api

that is consumed by

feature-something-impl

Does anyone have any relevant links?

How long does it normally take to get our plugin approved, I've been waiting approval for over a week.

gradle 9.1.0 how linux vs macos arm may influence on CC? on mac locally i have no problems (beside isVisible), but on linux it listed all runtime as problems. The only difference i see is java toolchain...

I have a list of dependencies that are located in other repos and sometimes that's not what you want when doing some experimentation So far I have been using

includeBuild()

to see changes without publishing. However going through the motion of removing version from version catalog and then putting it back seems like a bad way and there is probably a better one. If anyone knows of a better way please share your expertise, thanks

I'm migrating a project to using the modern gradle plugins block to define plugins. Im still using groovy though... not allowed to use kts. it seems like its not allowed to define a variable (like for a kotlin version number). and then reference that in my plugins. is that right? seems crazy to me, but just want a sanity check.

I have a CI job that has a

build

job that compiles everything, and then a couple of downstream jobs that does some stuff with the built artifacts. The

build

job starts with restoring

~/.gradle/shared_cache/modules-2

and sets the

GRADLE_RO_DEP_CACHE

environment variable to this and saves that path to CI cache at the end after having rsync'd any delta. Downstream jobs restore that shared cache and maintains their own cache of

~/.gradle/caches/modules-2

with for example runtime dependencies that aren't available in the shared cache. While this works nice I noticed that it's still pretty slow and with

--info

I noticed what it looks like http lookups of manifests for the dependency verification feature. I was under the impression that this would be a no-op given that I have a warm cache with all my dependencies now, so I put that to the test and added

--offline

argument to the build and this made the build fail with

checksum is missing from verification metadata

. So how do I avoid dependency verification needing network access? If I search my local

~/.gradle

directory for

.asc

files, the

modules-2

directory is the only one that matches, so these should be available in the cache already. Is this a current limitation that

GRADLE_RO_DEP_CACHE

doesn't allow for resolving dependency verification signatures? I'm using a checked-in keyring, and have keyservers disabled in the

verification-metadata.xml

with the goal of not needing network access.

I'm trying to build my first Android app using Kotlin and Gradle (using Zed editor). Fundamentally, I am unable to make any corrections to my build.gradle.kts file as every time I edit the file, something just reverts it on me. What is going on?

Is there a gradle code search (similar to cs.android.com) ? For example... I'm just trying to find what mavenCentral() and google() actually resolve to in gradle but github search is atrocious.

subprojects {
    tasks.register("foo") { … }
}

ELI5 why does this break configuration avoidance? It's using

register

which makes task instantiation lazy.. so what's the problem? Docs basically just say its bad because it injects code not visible at project build file (sure), and it introduces comfiguration time coupling (not sure what does it mean) How exactly am I tanking perf by this?

This message was deleted.

👋 While doing a code-review for someone's gradle plugin, I just encountered something I hadn't seem before, and want to know whether there's any basis for my suspicion. Basically, the are registering an extension for their plugin, but instead of using it for configuration, they are using it to expose properties that they then wire up as inputs to other tasks. For example:

def myExtensionOutput = extensions.getByName("myExtension").outputFilePath

tasks.register("someTask") {
  inputs.file(myExtensionOutput)
}

The reason they do this is because the file at the output path is expected to just be there as a result of a previous task execution. There is no implied dependency on the source task in the graph. My question is, is this wrong? Why? It feels wrong to me but I can't think of any actual problem they'd encounter and I'd like to check my assumptions. (clearly the better solution is to pass the path in as a property/env-var/well-known-file, and that's what I've recommended)

android-ish question, but every dependency defined with

implementation

is automatically also available in

androidTestImplementation

right? Same goes for unit tests. So you don't have to redefine every dep to be implementation and testImplementation right?

Is there a way to somehow have groups of projects, and then select which one is active? We currently have a big build with 400 modules (multiple apps). Local dev machines are managing just fine, so I'd like keep is this way - and having ability to build everything in one command is a superpower which I obviously want to keep. But not every team needs such bird's eye view of the whole build, mostly they're working on their part of the codebase. And some voiced that it would be nice if they only saw their part & it's dependency modules, to scope down the complexity Obvioulsy I know I can "hack" it via commenting out the projects in

settings.gradle

But isn't there something more sophisticated? Other than flipping it on its head, having per app builds & then one composite one (which I would not prefer)

any resources on how to best use setup-gradle github action? a teammate setup our gradle action and it's realllllly not good. two examples, they're extracting the version number of gradle from our project, instead of just relying on the gradle wrapper... and theyre also pulling in some

cache

github action and trying to cache certain downloads from gradle there. i have 0 experience setting up github actions with a gradle+android project (i usually use bitrise) so im unsure if this sort of caching thing is just handled for free when using the official gradle step. thanks!

Hi - I need to upgrade from

com.github.johnrengelman.shadow:8.1.1

to

com.gradleup.shadow:9.2.2

, and it breaks some of my existing gradle config. Details in thread.

Related to my last question. Does anyone know how to run github actions locally with the setup-gradle action? I've been looking at using nektos/act which seems popular as a local github action runner, but it doesn't support setup-gradle v4 or v5 (it does seem to work fine with v3 tho). Just wanna see if theres something the gradle community uses already