In previous official samples, there was always the...

# gradle

[Daniele B]

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.

[Vampire]

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.

[Daniele B]

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?

[mbonnin]

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

[mbonnin]

If you don't have buildSrc /`build-logic` , I guess root project, apply false + ids in subprojects would work too

[mbonnin]

But buildSrc /`build-logic` allow you to factor your build logic with convention plugins and once you have a lot of modules, this becomes handy

[Daniele B]

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!

[mbonnin]

it gives me some gradle errors

Interesting. Can you share them? I'm curious what pluginManagement.plugins does now 🙂

[mbonnin]

The javadoc isn't super chatty

[Daniele B]

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)

[Daniele B]

Screenshot 2023-02-28 alle 23.59.48.png

[mbonnin]

Searched in the following repositories:
    Gradle Central Plugin Repository

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

[mbonnin]

But you have it in your pluginManagement.repositories {}

[Daniele B]

Ah, wait, I had removed the pluginManagement section. I will now, put it back, without the plugin subsection

[mbonnin]

Ah yes, that'd explain it. By default only gradlePluginPortal() is there

[Daniele B]

great! it actually works! 😄

[Daniele B]

thanks!

[Daniele B]

@mbonnin the annoying thing is now that it doesn’t read the gradle.properties

[mbonnin]

Aww yea, plugins {} is "special"

[mbonnin]

It's a very constrained Kotlin syntax, you can't use much

[mbonnin]

The new way to do this would be to put your versions in a version catalog

[mbonnin]

Now in android has what is considered a "modern" setup: https://github.com/android/nowinandroid/blob/main/build.gradle.kts#L29

[Daniele B]

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

[mbonnin]

😅

[mbonnin]

"Don't fix it if it ain't broke" I guess

[mbonnin]

The version catalog is good though, it put everything in a central place that tools can process and it's nice to be able to quickly locate dependencies when coming in in a new project

[mbonnin]

(it's there in the now in android project)

[mbonnin]

At the end of the day, do whatever works for you!

[Daniele B]

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

[Vampire]

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. :-)

[Vampire]

Why do you say it is messy? What do you mean?

[Vampire]

It's already stable, so there will probably not be too deep changes in the upcoming versions

[Daniele B]

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

[Vampire]

Which other files? confused

[Vampire]

You put the versions, libs, and plugins in there and then you can use them already, no other files involved

[Daniele B]

mmm, ok I will try

[mbonnin]

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

[Vampire]

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.

[Daniele B]

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

[Vampire]

Is that your root builds settings script?

[Vampire]

Then don't try to define the default file there, it will fail and is unnecessary

[Daniele B]

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

[Vampire]

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

[Vampire]

Yeah, then as I said, don't redeclare the conventional file, that will fail and is totally unnecessary

[Daniele B]

where should I place it?

[Vampire]

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

[Daniele B]

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?

[Vampire]

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.

[Vampire]

Just create the file, put the versions, libs and plugins in there and you are ready to use them as I said multiple times

[Vampire]

You only need that code if you want to put the file into a non-standard place / name, or if you want to have multiple files with different name-spaces

[Daniele B]

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

[Daniele B]

what should I type?

[Vampire]

Not in the root folder, in the gradle folder

[Daniele B]

ah ok

[Daniele B]

ok, it’s in the gradle folder now
but if I type libs. in any gradle file, nothing comes up

[Vampire]

Did you sync?

[Daniele B]

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)

[Daniele B]

here:

plugins {
    id("org.jetbrains.compose")
    id("com.android.application")
    kotlin("android")
}

[Vampire]

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

[Vampire]

You still need the repositories in the plugin management block if you need something else than the gradle plugin portal

[Vampire]

Or rather, you probably removed the plugins block that defined the versions

[Vampire]

And now it cannot find the plugin without version of course as you do not use the version catalog yet but still have the plugins via I'd in the build script

[Vampire]

As it is new to you, don't change to much at once. Take your working build as base, add the file, sync, then use the version catalog and remove the non version catalog usages

[Daniele B]

yes, trying now to re-establish how it was

[Daniele B]

wow! finally!!!

[Daniele B]

now I get all these values with libs. !!!

[Daniele B]

it actually wasn’t hard 😄 but if you read the documentation and see the androidnow sample, it looks confusing

[Daniele B]

many thanks for your support 🤗🤗🤗

[Vampire]

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.

[Daniele B]

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!