In a Java CLI app I'm using Logback as the logger implementation. After starting to use the Gradle Tooling API in the app, I started to get

java.lang.ClassCastException: class org.gradle.internal.logging.slf4j.OutputEventListenerBackedLogger cannot be cast to class ch.qos.logback.classic.Logger

. So, looks like Gradle is overriding the root logger of my app. Any idea how to avoid that?

one feature that I liked about buildSrc is that I could define the Maven coordinates of all the plugins I wanted to use in

buildSrc/build.gradle.kts

, and the plugin versions would be the same in both the convention plugins, and if they were applied directly in subprojects. I liked that there was one central place were the plugin versions were defined. When I change from buildSrc to an included build, I lose this feature. Even though the plugins are still defined in

build-logic/build.gradle.kts

I have to specify the plugin version again in subprojects. This means there's not a central place where plugins are defined. I know there's plugin aliases in

libs.versions.toml

, but I'm not a fan of this because the kts implementation is janky ("val Project.libs: LibrariesForLibs' can't be called in this context..."), and I have to define both the plugin ID and the Maven coordinates. I preferred the buildSrc method. Is there a nice way of having all the plugins defined in one place while using included build?

Trying to build a project I get

data-store-api % gradle clean test --scan
> Task :compileTestFixturesGroovy FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':compileTestFixturesGroovy'.
> Cannot infer Groovy class path because no Groovy Jar was found on class path: [/Users/eric.kolotyluk/git/autonomous-iam/eps/data-store-api/build/libs/data-store-api-1.0-SNAPSHOT.jar, /Users/eric.kolotyluk/git/autonomous-iam/eps/data-store-api/build/classes/java/testFixtures]

Looking at the scan I can see that while Groovy is on the

compileClasspath

it is not on the

testFixturesCompileClasspath

where I would have assumed

compileTestFixturesGroovy

could have gotten it from the

compileClasspath

Is this expected behaviour? It is new behaviour that has changed after upgrading to Java 11, Groovy 4, and the latest version of Spock. My

build.gradle

looks like

// mandatory dependencies for using Spock from <https://github.com/spockframework/spock-example/blob/master/build.gradle>

    implementation platform("org.apache.groovy:groovy-bom:${apacheGroovyVersion}")
    implementation "org.apache.groovy:groovy"

    testImplementation platform("org.spockframework:spock-bom:${spockVersion}")
    testImplementation "org.spockframework:spock-core"

Is it somehow possible to map {} a filtered list of tasks. Something like mapEach {} as in configureEach {} I would like to do this in a "nicer" way (if possible):

// JaCoCo report for *all* Test tasks in the project
jacocoReport.executionData(project.tasks.withType(Test::class.java).map { testTask ->
  // The 'map' above is the normal 'map' on collections, we loose the task dependency information
  jacocoReport.dependsOn(testTask)
  testTask.extensions.getByType(JacocoTaskExtension::class.java).destinationFile
})

Also related: TIL

ReportingExtension

and that you could do (since 7.4):

reporting.reports.register("myownReport", JacocoCoverageReport::class.java) { report ->
  report.testType.set(TestSuiteType.UNIT_TEST)
  report.reportTask.configure {
    // ...
  }
}

This always binds the task to a specific "testType" – or a specific test suite. And with that to one test task. Is there some recommended way to setup a report for all suites (all test tasks). If I want the coverage of everything? Something planned in that direction?

I have included builds that use a (script) settings plugin from another included build (to avoid duplicating complex plugin repo definitions). This worked fine so far, but starting from 7.6, I cannot use

-x

on the commandline anymore, else I get this (in under 1s, with only "org.gradle" in the stacktrace):

The default project is not yet available for build.

This even happens when my script plugin is empty and its build only applies the

groovy-gradle-plugin

and does nothing else. My included-build `settings.gradle`s look somewhat like this:

pluginManagement {
    includeBuild '../conventions'
}

plugins {
    id 'script-plugin' <<<< this causes the error, -x works fine without it
}

I have a minimal reproducer I could share, so it's not anything else that my build is doing. This feels like a bug, when

-x

breaks a setup that works fine otherwise, but I might be doing something unsupported with this setup. Do you have any hints on how I could resolve this problem? Or maybe better ways to avoid the plugin repo duplication than a settings plugin?

Hi everyone, what could be the best way to run a few jobs parallelly in a Transform Action? 🤔

Gradle docs say that

google()

repo is at

<https://dl.google.com/dl/android/maven2/>

which 404's. Should I be using a different declaration for googls maven

Morning everyone, we've got an interesting bug in our project that is pretty difficult to troubleshoot. Essentially, our project is configured with Gradle Enterprise and a remote cache. The remote cache is written to every time a CI job runs and we also have a Jenkins pipeline that writes to it periodically (every 30 minutes) for some common tasks (example:

assemble

). The bug: Sometimes, a developer will add a new empty module to the project: • no dependencies in the gradle script • no source files in the module • just adds the module with

build.gradle

that specifies whether it's an android library or a kotlin library • adds it to the

settings.gradle

• updates the

CODEOWNERS

file for Github • DOES NOT attach it to the project graph, meaning it's not reachable from the

:app

module • no other project module depends on it This seems like a trivial change. There's no source files and the module is unreachable. But, when the dev opens a PR and CI runs against these changes we start seeing failures and the failures are not always. For example, in our most recent case we experienced:

com.example.App-mergeDebugResources-149:/values/values.xml:123: error: resource drawable/ic_gradient_border (aka com.example:drawable/ic_gradient_border) not found.

for multiple resources. In another case, we experienced

Unresolved reference: GeneratedClass

for generated proto classes. What I'm trying to convey is that the error is not always the same. What we've discovered is that if we purge (delete) the cache entries whose output was used for these files/resources from the remote cache, (in these cases the tasks that generate

ic_gradient_border

resource or

GeneratedClas

class file) the failure goes away! In other words, if the task that generates the class file for

GeneratedClass

is

:example-library:generateProto

and we see that its output was a cache-hit on the remote cache (

FROM-CACHE

) (which is always the case for these errors), when we delete the cache entry from all remote cache nodes, the error goes away when we re-run the failing task. We've also discovered that renaming the new module the dev introduced also fixes all the issues. Thus, we know this is an issue with our remote cache, we just don't have consistent reproducible steps as this only happens sometimes a dev introduces a new empty module. Anyone else run into a similar issue or any ideas on what could be happening here?

hello 👋 what is the proper way to generate a file and add it to a source set? i.e. I wrote a task that generates a file with version info (link) + configured source set to include it + made compile task depend on the custom task This works great.... but Gradle complains (actually blows up in v8) that another task

publishPluginJar

does not depend on my custom task yet uses its output. I find it confusing as I'd assume in order to publish a JAR it would have to compile it first which already has proper dependency.... I could add the explicit dependency on the task but I'm wondering whether I am missing something else?

I want to use a

ExtensiblePolymorphicDomainObjectContainer

to capture various types of data from plugin users. On paper this seems like a good idea, because I can define a common interface and the implementing classes can have the correct

@Input

@InputFiles

etc annotations But when I try to use

ExtensiblePolymorphicDomainObjectContainer

in a task, I find I can't re-use the values that were added to the container in my extension. I get an error:

this type is not known to this container

Is it possible to re-use a

ExtensiblePolymorphicDomainObjectContainer

in a sensible way? Or is there an alternative? I found this issue, but it's not had an update https://github.com/gradle/gradle/issues/20833 Example in the thread 🧵

My project build is frozen with a Gradle build: Configure projects, what is wrong?

What's the recommended way to name projects? I tend to have my projects look like:

projectName/
  app/
    build.gradle.kts
  backend/
    build.gradle.kts
  shared/
    build.gradle.kts
  build.gradle.kts
  settings.gradle.kts

However, when I publish them, they are of the shape

<my-group>:app:<version>

,

<my-group>:backend:<version>

and

<my-group>:shared:<version>

instead of

<my-group>:projectName-app:<version>

,

<my-group>:projectName-backend:<version>

and

<my-group>:projectName-shared:<version>

, meaning my different repositories will overwrite each other's artifacts! Yet, if we're expected to add the project name to the folders:

projectName/
  projectName-app/
    build.gradle.kts
  projectName-backend/
    build.gradle.kts
  projectName-shared/
    build.gradle.kts
  build.gradle.kts
  settings.gradle.kts

then the typesafe project accessors are generated as

project.projectNameApp

which is obviously less readable, especially when the repository has multiple subprojects (

project.extra.example

becomes

project.extra.projectNameExtraExample

, etc).

I have a couple of Gradle task that performs some validation (e.g. binary update checks, a custom task that checks text in the README is up to date, and the Gradle plugin strict-validation checks). These tasks throw an exception in the task action if they fail. However, it’s a little bit annoying that failures don’t appear in the test failure report, nor in in IntelliJ when I run the

check

task these tests don’t appear nicely alongside the JUnit tests. And I would like it if the default was to continue-on-error, so a failure in one subproject doesn’t stop other checks. Is it possible to dynamically or programatically ‘create’ a unit test via a Gradle task, without writing a

@Test

? So that these checks will be picked up by any test listeners via the Test Launcher API, appear in the rest report, and ideally IntelliJ will be able to display it nicely as an error?

hey folks. I though I was going to nail it, but I didn't. I have an issue with my Micronaut plugins testing, in particular testing combinations of plugins.

Is it possible to apply gradle plugin written in Kotlin that resides in

buildSrc

in a regular groovy build.gradle file? I am trying using

apply plugin: PluginName

but it fails with

Could not get unknown property 'PluginName' for project ':app'

.

Is there a known (serialization) problem with Gradle plugins written in Kotlin that implement a

ToolingModelBuilder

? In the model that I build all lists are empty despite me filling them in the model builder, whereas primitive string types are returned correctly to the host application.

How can I, using the Tooling API, get to know the repository / URL from where artifacts were resolved from?

I'm writing a Gradle Plugin that uses the Worker API to execute a 3rd party library. Of course my project needs a compileOnly dependency on the 3rd-party-lib, and I've set up a custom Configuration to get the the lib for the Worker API runtime. It's all working, however, I need to completely hide 3rd-party-lib from the public API, so users don't need to manually add a dependency on it. Is there a way of setting up two source sets, one that has compileOnly dependency on 3rd-party-lib and contains the Worker API code, and another one that's isolated and that definitely does not depend on 3rd-party-lib, and then both source sets get packaged into a single Gradle Plugin jar? Is there a name for this? Is there a way/example of doing this in Gradle? I see there are feature variants, but I don't think that's what I want because there's only one 'variant'. Also, I'd prefer not using Shadow.

Is there a way to configure gradle to not resolve

rc

versions of dependncies?

I keep having this error but my build.gradle.kts has the compile kotlin set to 1_8 so any ideas? https://paste.gg/p/anonymous/6c2d16003fb74be089adec0168864cb2 -> Error https://paste.gg/p/anonymous/211698f58d8b4e2dae93967c9083bd73 -> Build.Gradle.Kts

Good day. There is a question (probably not the most difficult, but I haven't found the answer to it yet) - in which case does the gradle download the dependencies necessary for the task execution (before performing the task action itself) in CI? (to /.gradle/.tmp, this folder is not in the caches - there are standart .caches/.wrapper). We use Gitlab, the caches are connected, but we don't get the expected perf, i.e. either the caches are configured incorrectly, or we don't understand something. There is not a single @CacheableTask in our custom plugin, it is planned to fix this - but the behavior is relevant for all tasks used in the project (compileKotlin etc).

Do you have a (officially) naming convention for shared version catalogs?

Is there any API to bulk-delete published build scans created from the free version of Enterprise? And/or to list all uploaded scans?

Is it possible to disable a task based on a certain type via a fully qualified

String

name instead of a

Class<T>

?

Hey is there a way to store

org.gradle.jvm-test-suite

plugin reference in versions catalog? (to avoid strings in

plugin

block)

I just realized that calling

resolvedVariant.attributes.getAttribute(Category.CATEGORY_ATTRIBUTE)

in a Gradle plugin written in Kotlin returns

null

whereas using

resolvedVariant.attributes.getAttribute(Attribute.of("org.gradle.category", String::class.java))

succeeds. Is it expected that the category attribute seems to lose its dedicated type and "coerces" to String?

Does anyone know if you can apply version catalog customizations this way. We are creating the version catalog itself inside a convention plugin which also executing inside a

gradle.settingsEvaluated

block as well. I would think the

getByName

would fail if that handn’t been applied yet. However, I don’t see the actual version getting changed when doing it this way.

gradle.settingsEvaluated {
    dependencyResolutionManagement {
        versionCatalogs {
            getByName("internalLibs") {
                library("alias", "group:artifact:version"")
            }
        }
    }
}

Hello, when using JVM Test Suite with custom targets is it possible to configure the target’s test task in lazy manner? When doing

sit(JvmTestSuite) {
    ...
    targets {
        configureEach {
            testTask.configure {
                jvmArgs += "-Dparam=value"
            }
        }
    }

The line

jvmArgs += "-Dparam=value"

is executed every run during configuration phase even when running

clean

task. Is it possible to perform this configuration only when the task is actually needed?