let's say I have a

Test

task named

"testFoo"

. For Reasons, I want to register a lifecycle task (not a

Test

task), named simply

"test"

, which will have a

dependsOn

relationship with the original

"testFoo"

. Is there any way to propagate command-line options to the underlying "real" task? E.g., a test filter

--tests="*.foo.*"

?

Can I somehow enforce that convention plugin with defaults is applied everywhere? (Other than

subprojects

block)

FAILURE: Build failed with an exception. * What went wrong: Execution failed for task 'firebase authcheckDebugAarMetadata'.

A failure occurred while executing com.android.build.gradle.internal.tasks.CheckAarMetadataWorkAction

> 16 issues were found when checking AAR metadata: 1. Dependency ':firebase_core' requires libraries and applications that depend on it to compile against version 34 or later of the Android APIs. :firebase_auth is currently compiled against android-33. Recommended action: Update this project to use a newer compileSdk of at least 34, for example 36. Note that updating a library or application's compileSdk (which allows newer APIs to be used) can be done separately from updating targetSdk (which opts the app in to new runtime behavior) and minSdk (which determines which devices the app can be installed on). 2. Dependency 'androidx.activityactivity1.8.1' requires libraries and applications that depend on it to compile against version 34 or later of the Android APIs. :firebase_auth is currently compiled against android-33. Recommended action: Update this project to use a newer compileSdk of at least 34, for example 36. Note that updating a library or application's compileSdk (which allows newer APIs to be used) can be done separately from updating targetSdk (which opts the app in to new runtime behavior) and minSdk (which determines which devices the app can be installed on). 3. Dependency 'androidx.lifecyclelifecycle livedata core ktx2.7.0' requires libraries and applications that depend on it to compile against version 34 or later of the Android APIs. :firebase_auth is currently compiled against android-33. Recommended action: Update this project to use a newer compileSdk of at least 34, for example 36. Note that updating a library or application's compileSdk (which allows newer APIs to be used) can be done separately from updating targetSdk (which opts the app in to new runtime behavior) and minSdk (which determines which devices the app can be installed on). 4. Dependency 'androidx.lifecyclelifecycle livedata2.7.0' requires libraries and applications that depend on it to compile against version 34 or later of the Android APIs. :firebase_auth is currently compiled against android-33. Recommended action: Update this project to use a newer compileSdk of at least 34, for example 36. Note that updating a library or application's compileSdk (which allows newer APIs to be used) can be done separately from updating targetSdk (which opts the app in to new runtime behavior) and minSdk (which determines which devices the app can be installed on). 5. Dependency 'androidx.lifecyclelifecycle viewmodel2.7.0' requires libraries and applications that depend on it to compile against version 34 or later of the Android APIs. :firebase_auth is currently compiled against android-33. Recommended action: Update this project to use a newer compileSdk of at least 34, for example 36. Note that updating a library or application's compileSdk (which allows newer APIs to be used) can be done separately from updating targetSdk (which opts the app in to new runtime behavior) and minSdk (which determines which devices the app can be installed on). 6. Dependency 'androidx.lifecyclelifecycle livedata core2.7.0' requires libraries and applications that depend on it to compile against version 34 or later of the Android APIs. :firebase_auth is currently compiled against android-33. Recommended action: Update this project to use a newer compileSdk of at least 34, for example 36. Note that updating a library or application's compileSdk (which allows newer APIs to be used) can be done separately from updating targetSdk (which opts the app in to new runtime behavior) and minSdk (which determines which devices the app can be installed on). 7. Dependency 'androidx.lifecyclelifecycle viewmodel savedstate2.7.0' requires libraries and applications that depend on it to compile against version 34 or later of the Android APIs. :firebase_auth is currently compiled against android-33. Recommended action: Update this project to use a newer compileSdk of at least 34, for example 36. Note that updating a library or application's compileSdk (which allows newer APIs to be used) can be done separately from updating targetSdk (which opts the app in to new runtime behavior) and minSdk (which determines which devices the app can be installed on). 8. Dependency 'androidx.windowwindow java1.2.0' requires libraries and applications that depend on it to compile against version 34 or later of the Android APIs. :firebase_auth is currently compiled against android-33. Recommended action: Update this project to use a newer compileSdk of at least 34, for example 36. Note that updating a library or application's compileSdk (which allows newer APIs to be used) can be done separately from updating targetSdk (which opts the app in to new runtime behavior) and minSdk (which determines which devices the app can be installed on). 9. Dependency 'androidx.window🪟1.2.0' requires libraries and applications that depend on it to compile against version 34 or later of the Android APIs. :firebase_auth is currently compiled against android-33. Recommended action: Update this project to use a newer compileSdk of at least 34, for example 36. Note that updating a library or application's compileSdk (which allows newer APIs to be used) can be done separately from updating targetSdk (which opts the app in to new runtime behavior) and minSdk (which determines which devices the app can be installed on). 10. Dependency 'androidx.fragmentfragment1.7.1' requires libraries and applications that depend on it to compile against version 34 or later of the Android APIs. :firebase_auth is currently compiled against android-33. Recommended action: Update this project to use a newer compileSdk of at least 34, for example 36. Note that updating a library or application's compileSdk (which allows newer APIs to be used) can be done separately from updating targetSdk (which opts the app in to new runtime behavior) and minSdk (which determines which devices the app can be installed on). 11. Dependency 'androidx.corecore ktx1.13.1' requires libraries and applications that depend on it to compile against version 34 or later of the Android APIs. :firebase_auth is currently compiled against android-33. Recommended action: Update this project to use a newer compileSdk of at least 34, for example 36. Note that updating a library or application's compileSdk (which allows newer APIs to be used) can be done separately from updating targetSdk (which opts the app in to new runtime behavior) and minSdk (which determines which devices the app can be installed on). 12. Dependency 'androidx.corecore1.13.1' requires libraries and applications that depend on it to compile against version 34 or later of the Android APIs. :firebase_auth is currently compiled against android-33. Recommended action: Update this project to use a newer compileSdk of at least 34, for example 36. Note that updating a library or application's compileSdk (which allows newer APIs to be used) can be done separately from updating targetSdk (which opts the app in to new runtime behavior) and minSdk (which determines which devices the app can be installed on). 13. Dependency 'androidx.lifecyclelifecycle runtime2.7.0' requires libraries and applications that depend on it to compile against version 34 or later of the Android APIs. :firebase_auth is currently compiled against android-33. Recommended action: Update this project to use a newer compileSdk of at least 34, for example 36. Note that updating a library or application's compileSdk (which allows newer APIs to be used) can be done separately from updating targetSdk (which opts the app in to new runtime behavior) and minSdk (which determines which devices the app can be installed on). 14. Dependency 'androidx.lifecyclelifecycle process2.7.0' requires libraries and applications that depend on it to compile against version 34 or later of the Android APIs. :firebase_auth is currently compiled against android-33. Recommended action: Update this project to use a newer compileSdk of at least 34, for example 36. Note that updating a library or application's compileSdk (which allows newer APIs to be used) can be done separately from updating targetSdk (which opts the app in to new runtime behavior) and minSdk (which determines which devices the app can be installed on). 15. Dependency 'androidx.exifinterfaceexifinterface1.4.1' requires libraries and applications that depend on it to compile against version 34 or later of the Android APIs. :firebase_auth is currently compiled against android-33. Recommended action: Update this project to use a newer compileSdk of at least 34, for example 36. Note that updating a library or application's compileSdk (which allows newer APIs to be used) can be done separately from updating targetSdk (which opts the app in to new runtime behavior) and minSdk (which determines which devices the app can be installed on). 16. Dependency 'androidx.annotationannotation experimental1.4.0' requires libraries and applications that depend on it to compile against version 34 or later of the Android APIs. :firebase_auth is currently compiled against android-33. Recommended action: Update this project to use a newer compileSdk of at least 34, for example 36. Note that updating a library or application's compileSdk (which allows newer APIs to be used) can be done separately from updating targetSdk (which opts the app in to new runtime behavior) and minSdk (which determines which devices the app can be installed on). * Try:

Run with --stacktrace option to get the stack trace.

Run with --info or --debug option to get more log output.

Run with --scan to generate a Build Scan (Powered by Develocity).

Get more help at help.gradle.org.

i need help

Gradle server exited unexpectedly with code 1. Last output: Unrecognized option: --add-opens=java.base/java.util=ALL-UNNAMED | Error: Could not create the Java Virtual Machine. | Error: A fatal exception has occurred. Program will exit. Run 'Developer: Reload Window' if Gradle stops working.

I'm continuing my forray into making my companies gradle build faster. Right now the configuration phase seems to be the most problematic. We have a fairly simple app in my opinion but the complexity comes into play (i think) from the fact that we have a buildSrc to make convention plugins so that each module added to our app gets all of the typical dependencies and configuration (its an android app). it kills me when i make a change and then see gradle configuring for like 12 seconds on such a simple app. Recently ive been trying to resolve this by giving claude a goal to keep iterating until it finds a meaningful improvement. I initially thought going from buildSrc to build-logic would do the trick but it ended up with worse perf. Seemingly the only change that meaningfully improved things was converiting to a binary kotlin plugin away from *.gradle.kts. After all of this experimentation, im sitll left sorta banging my head against a wall with the question of "if i have two android library modules in my app, what's the BEST way to share a standard configuration (api level, etc) and set of dependencies between them?" I know a lot of answers in software are "it depends" but surely theres like a 99th percentile answer that would be the go-to way for each app, right?

Am I right that version catalogue bundle doesn't provide the configuration. The use case - I have one open source library and there is lint rules for it but from a different person/organisation. So far I need to define two dependencies - testImplementation and lintCheck. And if I want to avoid it the only way would be a convention plugin.

./gradlew :app:decryptSecrets --key=...
./gradlew :app:assembleRelease

Currently I have a task which decrypts secrets, and then assemble task has a provider which reads the properties (once decrypted) and uses them to sign release build (android)

def signingProperties = providers.fileContents(layout.projectDirectory.file("signing.properties")).asText
            .map {
                def properties = new Properties()
                properties.load(new StringReader(it))
                properties
            }

android {
    signingConfigs {
        release {
            def props = signingProperties.getOrNull()
            if (props != null) {
                keyAlias props["keyAlias"]
                keyPassword props["keyPassword"]
                ...
            }
        }
    }
}

It works. Now, for more performance I was hoping to turn this into a single

gradlew

invocation =

./gradlew  :app:decryptSecrets --key=... :app:assembleRelease

but im running into this kinda obvious issue of

def props = signingProperties.getOrNull()

getting evaluated at config time, and obviously the signing properties are not decrypted yet, so they dont exist, they become available only after

decryptSecrets

finishes So is this even possible? To have the properties wired somehow in only at execution time so I can run the two in one invocation? Or, is this a bad idea

Not sure if this is a known issue, but I hit a problem with the build cache after changing the name of a sub-project. I had a project nested under my parent project and referenced it in the

settings.gradle

file like this:

rootProject.name = 'my-service'
include ':public-api'
project(':public-api').name = 'my-service-public-api'

but then I decided to do things differently and changed that to simply:

rootProject.name = 'my-service'
include ':public-api'

but the build cache was confused. The

public-api

sub-project is generating Java code from Smithy specifications. It seems that the

spotless

code formatting plugin was now stuck looking at the old path for the generated code because of the build cache. Clean builds didn't help, I had to manually delete

~/.gradle/caches/build-cache-1

. Is this a Gradle problem or a spotless plugin problem? (or a me problem? 🙁 )

Hello, I created an account so I can publish plugins, but it has the wrong name and image: plugins.gradle.org/u/tehgeek I'd like to change it but I can't find where to. Could someone help me change the name and image?

is there any way to use the ad hoc tasks API to add a command line

@Option

to a task? My use-case is in an Android project. It has tasks like

testDebugUnitTest

and

testReleaseUnitTest

, as well as a lifecycle task

test

that depends on each of those two variant-specific Test tasks. I would love to add a

--tests

option to this preexisting (from another plugin, I do not control it)

test

lifecycle task. I've tried this, but it doesn't work:

project.tasks.named { it == "test" }.configureEach {
  inputs
    .property("tests", "") // passing no value as a test
    .optional(true)
}

I still get

> Unknown command-line option '--tests'.

👋 Hi, is there a way to find the build that uploaded the Build Cache entry containing this metadata values ?

buildCacheKey=b4c52b0ffac21f5823d8cb885f76413b
buildInvocationId=bueeaav7o5fazlizc4e6fajtwa

We are currently observing build entries being overwritten with empty content (only the METADATA file and 3 empty directories):

cache-entry-b4c52b0ffac21f5823d8cb885f76413b
├── METADATA
├── tree-classpathSnapshotProperties.classpathSnapshotDir
├── tree-destinationDirectory
└── tree-taskBuildCacheableOutputDirectory%24kotlin_gradle_plugin_common

4 directories, 1 file

(the

%24

url-encoded name of the last directly looks suspicious as well)

org.gradle.execution.TaskSelectionException: Task 'prepareKotlinBuildScriptModel' not found in project ':app'., this error is appearing again and again.

How should we report spam in this community? I'm getting some unwanted solicitation here

Hi folks. I'm sure this has been asked before (maybe even by me), question about this kind of migration. I have an Android project with dependencies like this:

MyApp

depends on

depA

, which depends on an old version of

depB

:

MyApp -> depA -> depB

I want to break the dependency on

depA

and instead depend directly on a new version of

depB

. However I need to keep the previous arrangement, to support a gradual rollout of the change:

MyApp
  -> depB
  -> depA -> depB

From talking to Claude I am under the impression this is basically impossible, since there will be conflicts on the classpath. Yet this seems like it may be a common requirement for projects, so I'm wondering how other people handle this. Thanks for your time.

Hello guys, i have

--refresh-dependencies

parameter everytime at CI build job. But sometimes i get Cound not get HEAD from some pom file from maven central or Count not GET another lib. Is there possible, that the parameter causes this issues ? Maybe a few pipelines asks maven central very frequently and we get some anti DDOS blocks? Is there any way to add retry logic when gradle tries to fetch remote dependencies and failed could it try again from the same repository? If i remove this, is there possibility to break something on CI builds? Thank you for answering

I have a library that produces two variants - one for JDK8 and one for JDK17+. The latter variant has one more transitive RUNTIME dependency. If I write a plugin that consumes this library and I compile it against JDK17 it does select the correct variant (and also for JDK8). Also if you write a build.gradle which uses a plugin that uses the above library it will select the correct variant. But what I want to do in my plugin that I am writing is compile main against JDK8, then compile and run Testkit-based tests against JDK17. The problem is that the runtimeClasspath already selected the JDK8 variant and that is what appears on the plugin manifest. And the reason this is important is that I might want to test Gradle 8 running JDK8, but test against Gradle 9 running JDK17. That additional RUNTIME dependency has optimisations for Gradle9, but they don't get loaded in the tests due to the manifest problem and thus some bugs be missed. I have not really found a nice solution to this, so I would be interested in what people would suggest. (P.S. Please do not comment on the JDK versions used, they are for illustrative purposes only).

Hi, I maintain a library called sarif4k. This library is used by the detekt-gradle-plugin that supports gradle

8.14.3

. Detekt can't update to the last version of sarif4k because it uses a recent version of kotlin (https://github.com/gradle/gradle/issues/16345). The problem is not the library itself but its dependencies. My question, is there any tool I can run on sarif4k side to ensure that my library is compatible with certain version of gradle (or kotlin, I don't care, I can make the conversion). I want to run it on CI so this doesn't happen again.

Is Gradle 9.7.1 not on SDKMan!?

Anyone managed to run Gradle in claude sandboxed mode? I can make an exception for

~/.gradle

but I haven't found a way to allow the daemon to access the unix socket and I get things like this:

Sandbox networking is blocking Gradle's file-lock socket. Retrying without the sandbox.

Do you need to call

myParallelBuildService.get()

inside a task action if you use a shared build service without any parameters to only limit parallelism?

on linen.dev the 'copy thread link' button returns an invalid URL https://www.linen.dev/s/gradle-community/c/community-support When I click it https:///s/gradle-community/t/34316603/anyone-managed-to-run-gradle-in-claude-https-code-claude-com#d2e9b14a-b897-454e-9219-28fccb505685 is copied to the clipboard, but it should be http://www.linen.dev/s/gradle-community/t/34316603/anyone-managed-to-run-gradle-in-claude-https-code-claude-com#d2e9b14a-b897-454e-9219-28fccb505685

We have a 2 app repository and there are a large set of shared modules, not all are used across both apps, but the majority are. Ideally we would convert the shared modules into a composite build. The current setup is just a directory with direct

include

references. Our benchmarks show that we incur additional configuration load times in our build scans. Additional time to a cold configuration which would impact the ide-sync times by 25%. Is this an expected slow down or are we doing something wrong?

Is there an official best practice around setting attributes on configurations? I am seeing a lot of configurations in the ecosystem which get created with no attributes which causes ambiguity errors during variant selection

With the Isolated Projects changes, what is the recommended way to access arbitrary data from other projects. Specifically I am trying to access the Project.version and EclipseProject.name The first is needed for packaging metadata. The second is needed for me to generate run configs for eclipse considering it's not possible to debug gradle tasks in eclipse. I've tried looking into how the official Eclipse plugin does things. But it seems to just reach inside the other project like explicitly told not to do in the docs. It would also be useful to share other arbitrary data such as config values for custom plugin extensions. But figured i'd ask about vanilla gradle fields first.

hello everyone, with a coworker we have been experimenting with configuring a different kotlin version to compile our code and to compile the build as per this gradle blog article. Our main project is stuck on kotlin compiler 2.2 for now ( we tried 2.3 and the different bytecode triggers subtle bugs which will take time to resolve ) so until today we were stuck on gradle 9.3.1 which pulls kotlin 2.2.21. Today we spent some time upgrading everything to gradle 9.7.1. Since this is a largish build we actually have 2 multi-project builds : • a plugin build where we define our convention plugins and custom plugins. • the apps build which consumes the conventions and plugins to build our apps Our understanding from the article is that the plugin build should use kotlin gradle plugin 2.4.0 ( which is the version embedded in gradle 9.7.1) and we want our apps build to keep using kotlin 2.2.21 we managed to make this work in the normal process where we release the artifacts of the plugin build and pull them in the main build in pre-compiled form ensuring a performant enough build for everyone However when working on the plugins build locally we use an include build: we include the plugins build in the apps build. In that configuration all other things being equal a build scan correctly reports that we have 2 version of the kotlin compiler plugin in the build, 2.2.21 which is used by the projects of the main build and 2.4.0 which is used by the projects of the plugins build. unfortunately the apps build fails to compile with errors which seem to indicate that the code was compiled with kotlin 2.3. Is this to be expected, is there a way around it ? we probably won't be able to upgrade to kotlin 2.4 for the apps build anytime soon so the dev experience for build engineers is going to significantly degrade ( we are investigation local publication in order to work around this but its way more painful than the include build pattern )

Hi all! So I have an external artifact with shared build conventions that I import into another project. These build conventions consist of several Gradle plugins all distributed via a single JAR. The conventions are then used in two different ways, (a) directly in

build.gradle.kts

, so applied via the

plugins { ... }

block and (b) via project-specific build conventions, that apply the plugin and preconfigure it. Now it can happen that the JAR of one plugin of the shared build conventions is applied via the project-specific build conventions and directly in the

build.gradle.kts

(of course, different plugins) and in this case Gradle tells me

Error resolving plugin [id: 'plugin.applied.in.build.gradle.kts', version: '0.1.0']
> The request for this plugin could not be satisfied because the plugin is already on the classpath with an unknown version, so compatibility cannot be checked.

so I remove the

version

identifier from the

plugins {}

block. But then for another build convention plugin, that I apply on the root build, I get

Plugin [id: 'other.plugin.applied.in.root.build.gradle.kts'] was not found in any of the following sources:

- Gradle Core Plugins (plugin is not in 'org.gradle' namespace)
- Included Builds (None of the included builds contain this plugin)
- Plugin Repositories (plugin dependency must include a version number for this source)

even though the root build has project-specific build conventions applied before as well, which carry the JAR as a dependency as well. So I'm kind of puzzled why some

plugins {}

blocks need a version and others must not get one. I feel I'm doing something wrong.

How can you pass values from a file to Property for another task? I have a task that produces a Java

Properties

files, and I want to pass these properties to a `MapProperty<String, String>`:

`val propertiesAsMapProvider = providers.fileContents(
  writePropertiesToFile.flatMap { it.output },
).asText.map {
  it.byteInputStream().use {
    Properties().apply { load(it) } as Map<String, String>
  }
}

This looses the task dependencies...

With IDE Task Deprecation What is the replacement for adding extra properties to the eclipse model. Specifically trying to enable annotation processors, which the current solution is the goomph apt plugin. Buildship doesn't seem to have anything related to annotation processors in its code.

So I regularly have to clean out my

$GRADLE_USER_HOME/.gradle/caches/<version>/transforms

directory which is gathering multiple gigabytes worth of duplicated transformed libraries that get generated through my multi component build. Now I know Gradle is first about correctness and speed and secondly only cares about optimizing cache sizes and the like, but I really, really would love to have some option in Gradle to clear outdated / unused caches. Not only transforms, but in general also cache folders from older Gradle versions, old cached distributions and the like. I know I could write a script and do it myself in one go, but then Gradle daemons need to be stopped properly, no new Gradle daemons must be started (otherwise Gradle stumbles upon corrupted caches) and in general I think it's Gradle's task to deal with its caches, not only creating them, but also keeping them under control. Is anything planned in this direction / is there eventually a ticket that I could subscribe to that would deal with that?

Hi, I'm experiencing the issue below specifically when using Gradle 9.7.1 via the gradle wrapper.

./gradlew --version
...
Caused by: java.lang.ClassNotFoundException: org.apache.tools.ant.launch.AntMain

Reverting to Gradle 9.7.0 (manually updating

gradle-wrapper.properties

, since gradlew commands don't work) fixes this issue - output of

./gradlew --version

in thread. I had a project working with Gradle 9.7.1 as of a week ago but it seems to be failing now - is there any chance this is some form of upstream dependency issue?