How do I include a convention plugin from build-logic/src/main/kotlin/my-conventions.kts ? Using

id("build-logic.my-conventions")

throws * Exception is: org.gradle.api.plugins.UnknownPluginException: Plugin [id: 'build-logic.my-conventions'] was not found in any of the following sources:

when pulling out a library that can be released on its own to a maven repo (e.g. a REST API client) would that be a composite build or a module?

I just discovered that archive

AbstractCopyTask

, disable output caching if you call some methods,

fileMatching

for example. I would think it has to do with the action serializibility. github.com/gradle/gradle/commit/510d032ec36b…#…

project layout wise: I want multiple composite builds in a directory that build separate projects, but I'd like a single gradle wrapper and libs.versions.toml do I just move the wrapper up from the composite builds into the parent directory and do I want some kind of settings.gradle.kts in the parent directory?

let's say you have a couple common test utils in a separate composite build: where do these go? into the main/ or test/ folder? because it looks like everything in test is not exported If they go into main/ then I'd also need to depend on junit via implementation Edit: found the solution: java-test-fixtures plugin

I wonder how many of you put

-q

for your CI jobs already? I see huge but it looks like I'm not interested in. I have other tools to monitor times and cacheability. If something fails - it is still printed in log.

I'm trying out the new JvmTestSuite plugin but can't get junit tags to work

testing {
    suites {
        val test = named<JvmTestSuite>("test") {
            useJUnitJupiter()
        }
        register<JvmTestSuite>("integration") {
            dependencies {
                implementation(project())
            }
            targets {
                all {
                    testTask.configure {
                        useJUnitPlatform {
                            includeTags("integration")
                        }
                        shouldRunAfter(test)
                    }
                }
            }
        }
    }
}

import org.junit.jupiter.api.Assertions.*
import org.junit.jupiter.api.Tag
import org.junit.jupiter.api.Test
@Tag("integration")
class ProductControllerTest {
    @Test
    fun name() {
        assertEquals(1, 21)
    }
}

there are also no examples on how to configure junit. ./gradlew test executes the failing test, ./gradlew integration doesn't

About build cache on CI. When used with gitlab i need to set a cache key. Anybody have recommendations on how to manage this? From what I understand, is that whole thing is zipped up and uploaded into storage under the key. Which leads me to believe there is going to be cache clobbering if there are parallel feature branches triggering CI (obvious) Anybody got opinions on how to manage this? Maybe only let main branch upload the cache and features only consume?

I have my

checkDebug

lifecycle task In root build.gradle I define

def checkDebug = tasks.register("checkDebug") {
    group = "verification"
}

subprojects { subproject ->
    subproject.pluginManager.withPlugin("com.android.library") {
        tasks.named("checkDebug") {
            dependsOn("${subproject.path}:lintDebug")
            dependsOn("${subproject.path}:testDebugUnitTest")
        }
    }
}

How would I push this into convention plugin? Convention plugin is applied to each project, but there is no central place, so where do I register

checkDebug

once? Or is that not the way? If I register it in every project, it will be availabel to the CLI, but I wont be able to depend on it, so I cannot have my

buildAll

etc, which kills further composing, which is dumb What the idiomatic way of doing this with convention plugins?

Is there really 0 ways of expressing "task which checks everything everywhere and assembles app A" as a explicit task? i.e the equivalent of

./gradlew check :appA:assemble

but as a explicit

buildAppA

task? I really hate pushing complexity/impl details into cli / ci configs. It does not scale. Its what tasks are for

What's the intended way of depending on sourceSets across projects? I've got an

api

sourceSet in project-a, and then another

api

sourceSet in project-b, and i need to have project-b's

api

sourceSet depend on/pull in project-a's

api

sourceSet

/gradlew :appA:decryptSecretsData -Pkey=$APPA_SECRETS_KEY
./gradlew :appB:decryptSecretsData -Pkey=$APPB_SECRETS_KEY

currently on CI I need to decrypt secrets per app (its a convention plugin applied to each app), and I'm doing it this way, and it works however I'd like to have it be a single invocation

./gradlew :appA:decryptSecretsData -Pkey=$APPA_SECRETS_KEY :appB:decryptSecretsData -Pkey=$APPB_SECRETS_KEY

and this obviously doesnt work as the second

-Pkey

overwrites the first bla bla can I somehow scope the

-Pkey

to a task?

Is there a recommended approach to share repositories declarations between a multi module project and the included build-logic project? Both for plugins and dependencies. Currently I'm duplicating them in both

settings.gradle.kts

added an integration to this channel: linen.dev

I've got a composite build with a convention plugin; how do I reference files from that build? when using the project layout, it points to the project including the convention plugin

how do I use version catalogs in convention plugins? looks like the libs object is not available

added an integration to this channel: linen.dev

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