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?

Hello. tried to find more details on cacheChangingModulesFor in the docs, but did not succeed. I'am not sure what this actually caches and specifically if this affects composite builds? Could someone help me out? Thanks!

Does this ring a bell with anyone when using

--configuration-cache

?

> Class org.gradle.internal.instantiation.generator.AsmBackedClassGenerator$InvokeSerializationConstructorAndInitializeFieldsStrategy can not access a member of class org.gradle.api.internal.AbstractTask with modifiers "protected"

It's mentioned here, but there was no follow up: https://github.com/gradle/gradle/issues/21461 I suddenly get this for a task implementation after changing some things to make CC compatible. Everything looks good, and the error is weird because it is about a Gradle internal class. Just want to see if anyone has a hint, before I investigate further.

i created a convention plugin (kts), include the build at the root, then have a library (as a sister project) apply that plugin...but i see it is actually clashing with the classpath for slf4j. but...why is it adding this stuff there? I think it might be because of the

java-gradle-plugin

that i have within the conventions plugin, in the plugins{} block. what could i be doing wrong?

Is it possible to set destination dir of gradle Copy task lazily? Looks like Copy task doesn’t expose the output dir as a

DirectoryProperty

.

I realize Gradle's local cache for modules sometimes does not contain a Maven dependency's POM under "files-2.1", but only the binary descriptor under "metadata-*". Am I correct to assume that the latter basically contains the same information than the former, but in a more compact format? Also, is there a way (via the Tooling API) to enforce Gradle to download metadata in POM format?

How do I using Toolchain compile modules with different Java Versions while still allowing them to be put into the same jar Current issue I have 4 modules that can use Java 17 as they only run on systems using Java 17 but the rest use Java 8 so I need each of the other ones at Java 8 but when I build I always get: - Incompatible because this component declares a component, compatible with Java 17 and the consumer needed a component, compatible with Java 8 - Other compatible attribute: