In previous official samples, there was always the gradle plugin specified as classpath, in the project’s gradle file, as a dependency of the buildscript

buildscript {
    repositories {
        gradlePluginPortal()
        google()
        mavenCentral()
    }
    dependencies {
        classpath("org.jetbrains.kotlin:kotlin-gradle-plugin:${kotlin.version}")
    }
}

But in the latest multiplatform samples, the buildscript section is not included anymore. Does buildscript belong to an old way of configuring gradle, or is it still relevant today? Previously, the documentation of popular libraries such as Kotlin Serialization or SqlDelight required to have a classpath specified as a dependency of buildscript, but now not anymore.

Adding something to the buildscript classpath if you need its classes in the build script is fine. But adding a plugin artifact to the buildscript classpath and applying it using

apply...

is legacy and not recommended since years. Instead the

plugins { ... }

block is the proper way to apply a plugin.

thanks for the clarification! at the moment, this is what I am doing: I have this in settings.gradle.kts:

pluginManagement {
    repositories {
        google()
        gradlePluginPortal()
        mavenCentral()
        maven("<https://maven.pkg.jetbrains.space/public/p/compose/dev>")
    }

    plugins {
        kotlin("multiplatform").version(extra["kotlin.version"] as String)
        id("org.jetbrains.compose").version(extra["compose.version"] as String)
        ...
    }
}

this in the *project*’s build.gradle.kts:

plugins {
    kotlin("multiplatform") apply false
    id("org.jetbrains.compose") apply false
    ...
}

and then recalling the plugins in all target-specific build.gradle.kts (e.g. shared, jsApp, wasmApp, desktopApp):

plugins {
    kotlin("multiplatform")
    id("org.jetbrains.compose")
    ...
}

There seems to be quite a lot of duplication. Should all plugins be defined in the project’s build.gradle.kts too? and what’s the meaning of

apply false

?

Welcome to classloader hell 🤘 😃

apply false

is used to put the plugin jar in the root project classpath (so that I think they are not loaded several times by different projects, but don't quote me on this...) My rule of thumb is: put all your plugin jars in your

buildSrc

/`build-logic` implementation configuration then use ids in individual projects. I'm not sure about

pluginManagement.plugins

. Looks like they're used to define versions but you could as well define them in your root project

plugins {}

block and I think that'd work too

I just tried to define the plugins in the root project build.gradle.kts (with version and

apply false

), but it gives me some gradle errors, so I think they need to be defined first in the

pluginManagement.plugins

. When I have more time, I might try to investigate the

buildSrc

/`build-logic` way you suggest. Many thanks!

it gives me some gradle errors

Interesting. Can you share them? I'm curious what

pluginManagement.plugins

does now 🙂

The error is related to the

com.android.application

plugin, not sure why:

Build file '/Users/daniele/Dev/KMP/PSF_CMS/build.gradle.kts' line: 13

Plugin [id: 'com.android.application', version: '7.3.0', apply: false] was not found in any of the following sources:

* Try:
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

* Exception is:
org.gradle.api.plugins.UnknownPluginException: Plugin [id: 'com.android.application', version: '7.3.0', apply: false] was not found in any of the following sources:

- Gradle Core Plugins (plugin is not in 'org.gradle' namespace)
- Plugin Repositories (could not resolve plugin artifact 'com.android.application:com.android.application.gradle.plugin:7.3.0')
  Searched in the following repositories:
    Gradle Central Plugin Repository
    at org.gradle.plugin.use.internal.DefaultPluginRequestApplicator.resolveToFoundResult(DefaultPluginRequestApplicator.java:238)
    at org.gradle.plugin.use.internal.DefaultPluginRequestApplicator.lambda$resolvePluginRequests$3(DefaultPluginRequestApplicator.java:168)
    at org.gradle.util.internal.CollectionUtils.collect(CollectionUtils.java:212)
    at org.gradle.util.internal.CollectionUtils.collect(CollectionUtils.java:206)
    at org.gradle.plugin.use.internal.DefaultPluginRequestApplicator.resolvePluginRequests(DefaultPluginRequestApplicator.java:166)
    at org.gradle.plugin.use.internal.DefaultPluginRequestApplicator.applyPlugins(DefaultPluginRequestApplicator.java:101)
    at org.gradle.kotlin.dsl.provider.PluginRequestsHandler.handle(PluginRequestsHandler.kt:48)
    at org.gradle.kotlin.dsl.provider.StandardKotlinScriptEvaluator$InterpreterHost.applyPluginsTo(KotlinScriptEvaluator.kt:195)

Searched in the following repositories:
    Gradle Central Plugin Repository

Weird, looks like it's not searching in the Google maven repo...

Ah, wait, I had removed the

pluginManagement

section. I will now, put it back, without the

plugin

subsection

Ah yes, that'd explain it. By default only

gradlePluginPortal()

is there

great! it actually works! 😄

Aww yea,

plugins {}

is "special"

I just had a look, but it looks so messy, with many files involved

😅

the version catalog is a good concept, but the implementation of it is too messy i am sure it will get better in the next gradle versions

The plugins block in plugin management defines default versions for plugins that are used if no version is used when using a plugin in a plugins block. It's syntax is more relaxed than the syntax of the other plugins blocks, so that you can calculate versions for example. But yeah, use a version catalog. :-)

I like the concept of having a unique file where to list all versions and plugins, but I don’t see why there have to be some many other files involved. Maybe there could be a simpler example

Which other files? confused

mmm, ok I will try

I guess it's the convention plugins that add some files/build logic.

In that example there is one other file actually,

build-logic/settings.gradle.kts

as it references the same version catalog for as the parent build. Separate build by default have separate files unless you configure it differently.

To start with, “libs” doesn’t get recognized

Is that your root builds settings script?

yes, I placed it in “settings.gradle.kts”

If it is not, but some build logic project, don't try to use Groovy Syntax in a Kotlin file

where should I place it?

Again, you need to have nothing in the settings script if you name the file like the convention. Just put the versions libs and plugins in there and you are ready to use them

sorry, I can’t really follow what you mean. that gradle code is supposed to define where the toml file is, and I thought I had to place it in settings.gradle.kts, where else?

NOWHERE if you put the file in the default place, what's so hard to understand with that? I'm really lost in how else I should express it.

what you say makes a lot of sense and it’s very desirable, but I still can’t get it… I created a file

libs.versions.toml

in the root folder, with this content:

[versions]
kotlin = "1.8.0"
agp = "7.4.0-beta02"
compose = "1.4.0-alpha01-dev940"
ktor = "2.2.2"

[plugins]
android-application = { id = "com.android.application", version.ref = "agp" }
android-library = { id = "com.android.library", version.ref = "agp" }

but I can’t see how I can access this data

Not in the root folder, in the gradle folder

ah ok

Did you sync?

I did, but with

libs.

nothing comes up, and now it complains about the existing plugins:

Build file '/Users/daniele/Dev/KMP/PSF_CMS/androidApp/build.gradle.kts' line: 1

Plugin [id: 'org.jetbrains.compose'] was not found in any of the following sources:

* Try:
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

* Exception is:
org.gradle.api.plugins.UnknownPluginException: Plugin [id: 'org.jetbrains.compose'] was not found in any of the following sources:

- Gradle Core Plugins (plugin is not in 'org.gradle' namespace)
- Plugin Repositories (plugin dependency must include a version number for this source)
	at org.gradle.plugin.use.internal.DefaultPluginRequestApplicator.resolveToFoundResult(DefaultPluginRequestApplicator.java:238)
	at org.gradle.plugin.use.internal.DefaultPluginRequestApplicator.lambda$resolvePluginRequests$3(DefaultPluginRequestApplicator.java:168)
	at org.gradle.util.internal.CollectionUtils.collect(CollectionUtils.java:212)
	at org.gradle.util.internal.CollectionUtils.collect(CollectionUtils.java:206)
	at org.gradle.plugin.use.internal.DefaultPluginRequestApplicator.resolvePluginRequests(DefaultPluginRequestApplicator.java:166)
	at org.gradle.plugin.use.internal.DefaultPluginRequestApplicator.applyPlugins(DefaultPluginRequestApplicator.java:101)
	at org.gradle.kotlin.dsl.provider.PluginRequestsHandler.handle(PluginRequestsHandler.kt:48)
	at org.gradle.kotlin.dsl.provider.StandardKotlinScriptEvaluator$InterpreterHost.applyPluginsTo(KotlinScriptEvaluator.kt:195)

You did not, at least not successfully if it also does not build currently with that error. ;-)

yes, trying now to re-establish how it was

The Android now example also had nothing in settings script, only in the one of the included

build-logic

build as I mentioned previously. Actually, I don't think the docs are confusing there, but if your think so, you should open an improvement issue about it.

I will play around to find the ideal/simplest configuration and then I will see if I come up with some documentation improvements, many thanks!