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?

Hey — publishing a version catalog with the

version-catalog

plugin, using

.withoutVersion()

on most libraries and only

versionRef

on a BOM alias. Minimal repro:

// build.gradle.kts
plugins {
    `version-catalog`
}
catalog {
    versionCatalog {
        val versionAlias = version("mylib", "1.0.0")
        library("bom", "com.example", "mylib-bom").versionRef(versionAlias)
        library("core", "com.example", "mylib-core").withoutVersion()
    }
}

Generated TOML:

[versions]
mylib = "1.0.0"

[libraries]
bom = { group = "com.example", name = "mylib-bom", version.ref = "mylib" }
core = { group = "com.example", name = "mylib-core", version = "" }

If a consumer forgets to apply the BOM as a platform:

dependencies {     
   implementation(platform(libs.mylib.bom))
   implementation(libs.mylib.core) // no platform applied
}

...resolution fails with

Could not find com.example:mylib-core:.

— which makes sense once you know the empty version is intentional, but the error message doesn't hint at the cause at all. A couple questions: 1. Is there a way to make Gradle emit a clearer error here — something that mentions the missing platform/BOM rather than just a blank version? 2. Is

.withoutVersion()

+ BOM the recommended pattern for a multi-module library's catalog, or is there a more idiomatic way to enforce "must be used with platform X" at the catalog level? Trying to figure out if I should adopt this for my own multi-module project's catalog or just keep

versionRef

on every library instead.

Hello, recently came across news that Gradle cache nodes are deprecated and will not be available to use after end of this year docs.develocity.ai/bcn/21.2. Are there any alternatives of cache node? also do we know how can we able to get access to docs.develocity.ai/edge/2.2 or paying for the Develocity is the only option as we only use gradle cache node on CI side.. any help or suggestion will be appreciated!

We are using MavenArtifactRepository to wire our dependencies to our own internal Artifactory instance. User provide their id and artifactory token via their gradle.properties file ... everything pretty standard. But thing is. it happens quite often that the users have an invalid artifactory token. And if that happens and gradle needs to download from our artifactory server, the error that users see looks like this:

* What went wrong:
Plugin [id: 'org.gradle.kotlin.kotlin-dsl', version: '6.6.4'] was not found in any of the following sources:

- Gradle Core Plugins (plugin is not in 'org.gradle' namespace)
- Included Builds (No included builds contain this plugin)
- Plugin Repositories (could not resolve plugin artifact 'org.gradle.kotlin.kotlin-dsl:org.gradle.kotlin.kotlin-dsl.gradle.plugin:6.6.4')
  Searched in the following repositories:
    maven(<https://eu.artifactory.whatever.com/artifactory/foobarblub>)

Token invalid , download not possible, but a "not found error" In order to make our tooling more user friendly, we added a "ping" check to our toplevel settings.gradle file. Artifactory servers have a "ping" endpoint, so do a GET request ... and if that fails with a 401 or 403, the token is not valid, and we can print a nice error message. But: this means that any single gradle invocation sends such a "ping" to the Artifactory servers. And now we regularly see failures on our CI build servers with Artifactory complaining about "too many requests". Before we had this "ping" solution, we tried to somehow "catch" the actual "not found error" that I showed above, but I couldn't get that to work reliably. Any idea if/how we can reliably give "good" error messages when Artifactory downloads fail (because of that bad token), without hammering the servers with every gradle invocation?

Hi

I am getting this below error always in Android Studio while Synching the Project with Gradle Files. Any help from anyone please? FAILURE: Build failed with an exception. * What went wrong: Process 'command 'node'' finished with non-zero exit value 1 * Try:

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

Get more help at help.gradle.org.

CONFIGURE FAILED in 38s

Ran 'gradle update/upgrade' and tried to upgrade to 9.7.1_1 on macOS Golden Gate 27.0 (26A428) to: ==> Would upgrade 3 outdated packages gradle 9.7.1 -> 9.7.1_1 (157.4MB) When I run: Gradle to build my EAR I get: Downloading services.gradle.org/distributions/gradle-9.7.1_1-bin.zip Exception in thread "main" java.io.FileNotFoundException: downloads.gradle.org/distributions/gradle-9.7.1_1-bin.zip at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1727) at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1311) at java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:223) at org.gradle.wrapper.Install.forceFetch(SourceFile:2) at org.gradle.wrapper.Install$1.call(SourceFile:8) at org.gradle.wrapper.GradleWrapperMain.main(SourceFile:67) Downloading services.gradle.org/distributions/gradle-9.7.1_1-bin.zip Exception in thread "main" java.io.FileNotFoundException: downloads.gradle.org/distributions/gradle-9.7.1_1-bin.zip at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1727) at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1311) at java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:223) at org.gradle.wrapper.Install.forceFetch(SourceFile:2) at org.gradle.wrapper.Install$1.call(SourceFile:8) at org.gradle.wrapper.GradleWrapperMain.main(SourceFile:67) Downloading services.gradle.org/distributions/gradle-9.7.1_1-bin.zip Exception in thread "main" java.io.FileNotFoundException: downloads.gradle.org/distributions/gradle-9.7.1_1-bin.zip at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1727) at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1311) at java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:223) at org.gradle.wrapper.Install.forceFetch(SourceFile:2) at org.gradle.wrapper.Install$1.call(SourceFile:8) at org.gradle.wrapper.GradleWrapperMain.main(SourceFile:67)

Does anyone have practical examples for using

addLater

or

addAllLater

on a domain collection especially on a named collection?

@Vampire W.r.t. https://gradle-community.slack.com/archives/CAHSN3LDN/p1790009935682299?thread_ts=1790005987.739679&amp;cid=CAHSN3LDN I am pulling this into a separate conversation: I have noticed in the later Gradle 9 versions that if you have some task class that is statically compiled Groovy 3.x (plugin built under Gradle 8.x) and it uses a

onlyIf {}

within that class, it fails when configuration cache is active. I have not spent enough time investigating it, but the couple of times I saw it was enough to irritate me

I'm working on improving the UX of https://github.com/adamko-dev/dev-publish-plugin, a helper plugin for testing modules via publishing (without Maven Local, and build-cache friendly). It publishes to a local directory using a regular maven-publish repo, but adds addition up-to-date checks. One rough edge: if a project enables signing unconditionally (i.e. without something like

signing.setRequired { <project has tasks that publish to Maven Central> }

), then dev-publish also triggers signing, which fails on machines/CI without signing keys. Afaict it's not possible to disable signing per repository. The fix I'm looking at is skipping signing when only dev-publish tasks are in the task graph then disable the sign tasks (e.g. via

Sign.onlyIf {}

). But I'm not sure whether this should be a default opt-out behaviour, or an opt-in behaviour. Should dev-publish... 1. Automatically disable signing when only dev-publish tasks are requested? 2. Or just detect that signing is enabled but not configured, and warn/fail with a hint like "conditionally disable signing for local testing"?

Another thing: I want to use the Problems API to add a warning, but it doesn't log any message to console. This means when signing fails for dev-publish users basically only see the 'signatory not configured' failure, and it's hard to discover the softer warning which would help. Why aren't Problems API warnings printed to the console? Is there a way to make them move visible? Or should dev-publish use error-level warnings instead? Or dev-publish should log warnings to the console and via Problems API?

Can I react to a configuration being registered ? (Not configured)