Is there any channel about declarative Gradle to share my use case?

Context and a real use case of how it started: • Create a project containing a project for a Gradle plugin and another for a version catalog. • Both projects will be published to MavenCentral and/or Plugin portal. • They will be open source, so building a site, docs, and so on easily is "mandatory".

• Gradle plugin project:

hubdle {
    config {
        analysis() // detekt and sonar
        coverage() // Kover
        documentation {
            api() // Dokka
        }
        publishing { // support the publication to MavenCentral, snapshot, and Gradle portal repositories
            maven { 
                repositories {
                    mavenLocalTest() // add a custom custom repository for testing purposes
                }
            }
        }
        versioning {
            semver() // automatic versioning with git tags
        }
    }

    kotlin {
        jvm {
            features {
                jvmVersion(JavaVersion.VERSION_11)

                gradle {
                    plugin {
                        gradlePlugin {
                            plugins {
                                create("hubdle") {
                                    id = "com.javiersc.hubdle"
                                    displayName = "Hubdle"
                                    // rest of the configuration ...
                                }
                            }
                        }

                        pluginUnderTestDependencies(
                            hubdle.android.tools.build.gradle,
                            hubdle.jetbrains.kotlin.gradle.plugin,
                        )
                    }
                }
            }

            main {
                dependencies {
                     // ...
                }
            }

            testFixtures()
            testFunctional()
            testIntegration()
        }
    }
}

• Version catalog project

hubdle {
    config {
        analysis()
        coverage()
        documentation {
            changelog() // handle automatically the changelog for the plugin updates
        }
        publishing {
            maven {
                repositories {
                    mavenLocalTest()
                }
            }
        }
        versioning {
            semver()
        }
    }

    kotlin {
        jvm {
            features {
                gradle {
                    versionCatalogs {
                        catalog {
                            toml(rootDir.resolve("gradle/hubdle.libs.versions.toml"))
                        }
                    }
                }
            }
        }
    }
}

• Root project

hubdle {
    config {
        analysis()
        binaryCompatibilityValidator() // create `.api` files
        coverage()
        documentation {
            api()
            changelog() // automatically patch the general changelog for the project
            readme {
                badges() // automatically update readme badges (Kotlin version, Sonar, etc)
            }
            site() // mkdocs web page
        }
        nexus() // requirement to support publishing to MavenCentral/Snapshot repositories
    }
}

Even though there are a lot of lines there, there is not a single if-else and it does tons of things in a declarative way • Detekt • Sonar (Sonarcloud setup) • Code coverage (and its integration with Sonarcloud) • Mkdocs webpage • Dokka • Automatic patching of changelogs and the readme files • Automatic semver with git tags • Creating a Kotlin JVM project which supports the creation of a Gradle plugin or a version catalog • Being able to publish them to Gradle plugin portal and Maven Central • Multiple source sets for integration and functional tests And more that are based on custom tastes under the hood, like the usage of

main/kotlin

instead of

src/main/kotlin

, etc

New use case: • I have started playing with Kotlin compiler plugins, so I need to support using custom Kotlin

dev

versions I want my Gradle plugin support Kotlin Gradle plugin

2.+

versions What could I do if I had a subset of Kotlin or Yaml? Crying a lot if the configuration that someone has created for me is not enough, and creating a Frankenstein elsewhere. This perfect configuration will not ever exist. I am creating my own DSL for my purposes, and even so, I have to write the next workaround. What are the chances of someone creating a very limited DSL for a random person on the internet that fits all needs? With normal Kotlin plus Gradle, I can work around it

hubdle {
    config {
    // ...
        versioning {
            semver { //
                val hasSameTagPrefix: Boolean = providedTagPrefix == tagPrefix
                if (kotlinVersion.isNotBlank() && hasSameTagPrefix) {
                    mapVersion { gradleVersion ->
                        gradleVersion.mapIfKotlinVersionIsProvided(kotlinVersion)
                    }
                }
            }
        }
        testing {
            test { //
                systemProperties["KOTLIN_VERSION"] = kotlinVersion.orEmpty()
            }
        }
    }
}

fun GradleVersion.mapIfKotlinVersionIsProvided(kotlinVersion: String): String {
    // checks to avoid wrong provided Kotlin versions, wrong publiccations, and so on 
}

Do I need a Compose setup in KMP?

hubdle {
    config {
        ...
    }
    kotlin {
        multiplatform {
            features {
                compose() // add compose
            }

            common {
                main {
                    dependencies {
                        implementation(hubdle.jetbrains.compose.ui)
                        ...
                    }
                }
            }

            android {
                  main {
                      implementation(hubdle.androidx.random.lib)
                  }
            }
            jvm()
            jvmAndAndroid()
            ...
        }
    }
}

Those are real use cases for a declarative plugin that applies a lot of plugins in each project (10 or more per project). I have created more and more "wrappers" Kotlin projects: • JVM • Android (library and app) • KMP Features to support things like: • Java Application • Gradle plugins • Version catalogs • IntelliJ plugins • Java versions and toolchains • Coroutines • Compose • Serialization • SqlDelight • Molecule And more and more I don't even remember. Even so, each simple setup can be easily understood, and at the same time, it supports any level of complexity and fallbacks

plugins {
    alias(libs.plugins.some.random.plugin)
}

hubdle {
    kotlin {
        multiplatform {
            // fallback configuration
            kotlin { // KotlinMultiplatformExtension from KGP
                ...
            }
        }
    }
}

randomExtension {
     ...
}

I have created this custom DSL for me, with my tastes, fixing a lot of general workarounds under the hood. And even so... There are too many specific configurations in any project that are impossible to fix with a configuration-like language without creating a big snowball and/or a Frankenstein of mixed files and/or included builds like

buildSrc

or

build-logic

just to do a simple

if/else

and binds it via custom plugin or whatever with a limited Kotlin DSL, Amper, or whatever configuration language. Currently: • Someone or a team who knows Gradle creates the convention plugin and maintains it. • No-build engineers consume it Future: • Someone or a team who knows Gradle creates the whole Gradle logic with conventional plugins or custom functions and maintains it. • Someone or a team who knows Gradle creates the bindings for the Kotlin DSL and/or Amper and maintains it. • No-build engineers consume it In my opinion: • The tools to create declarative convention plugins exist. The Slack open-source plugin does that and my plugin was inspired by the Slack one too. • It is a bit annoying dealing with ordering issues, but as you are the owner of the convention, you can decide the order of everything and it is safe. • Except for non-lazy configuration third-party plugins you need to use and the abuse of

afterEvaluate

. Non-lazy configuration breaks creating those convention plugins easily (you need to deal with ordering problems).

afterEvaluate

must die, because it is a 2x1: it is a hack to deal with plugins that are old/wrong (non-lazy). This provokes old plugins can keep doing wrong things, and a new good convention plugin is forced to use it, so they are not "good" anymore.

@Anze Sodja I want to share this: https://pkl-lang.org But just to mention it is almost a 1:1 copy of Kotlin with Arrow Analysis applied. I would like that the Kotlin subset would have, at least, the same functionalities pkl has. I think it is a really good opportunity for one of the next options: • Creating a kotlin.conf.kts which should be that, Kotlin + Arrow analysis with the features of pkl and bindings to generate any config file or gradle files (anyone should be able to pass a parser to generate anything). • Pushing pkl to be an standard in the Kotlin ecosystem. I prefer the first, but the second is getting some of the work done and looks nice.

I cannot create Categories on Gradle Forums. Fix in progress

If all the power of Kotlin is allowed then there is no problem from my side. I guess it will be based more on functions than properties. But I am missing the point on why plugin authors are not being able to already do that with the tools we have. Picking this image from the recent talk from Louis Jacomet, the DSL on it is already possible to be created without any problem, but that depends on the authors and their tastes. For example, it is really similar to what I have:

hubdle {
    kotlin {
        multiplatform {
            apple {
                main { ... }
                ios {
                    main { ... }
                    test { ... }
                }
            }
            jvm {
                main { ... }
                test { ... }
            }
        }
    }
}

I kept the main/test approach which is not in the image, but I think it is necessary, as you could want to put dependencies only for the test set and not the main set. I understand you can have something like:

jvm {
    dependencies { ... } // main suppressed to avoid nesting for simple projects
    test {
         dependencies { ... }
    }
    integrationTest { ... }
    functionalTest { ... }
}

But everything is currently possible, just a matter of taste and/or trying to follow a missing standard on how to name or do some things. I still have to read the doc as I had no time, so I am just guessing.