This message was deleted.

idiomatic approach is to use a convention plugin as appropriate.

Please you elaborate on that. Can config be shared across modules or not?

Yes, by using convention plugins as Chris said. You could use

subprojects { ... }

too, yes, but you shouldn't. It is bad practice by now and as it adds project coupling prevents some more sophisticated Gradle performance features like configure-on-demand or parallel configuration. Besides that it makes builds less clear to read and harder to maintain.

is there a good article on implementing convention plugins? we dont use them yet, but sharing a spotless config seems like a good first task for me and my team.

if you use precompiled plugin it is the same than configuring the spotless on a project, but in buildSrc or an included build, and apply that plugin

My takeaway from this is that sharing plugin config is possible, but complicated, so ideal config is not really worth chasing

With buildSrc is simple, but custom included build is not hard either

It is simple either way, they are almost identical in effort. And as Javi said, if you use precompiled script plugins for your convention plugins, you write them almost identical to build scripts.

For smaller examples (shameless plugs): https://github.com/tbroyer/auto-delegate (uses buildSrc) and https://github.com/tbroyer/javac-diagnostics-serializer (uses an included build). The

local.base

plugin sets up Spotless for the

*.gradle.kts

, the

local.java-library

applies

local.base

and sets up Spotless for Java code. The root

build.gradle.kts

only applies

local.base

, whereas subprojects each apply the

local.java-library

plugin (and in javac-diagnostic-serializer, the gradle-plugin subproject also configures Spotless for Kotlin code)

Ok I think I got the idea behind convention plugins and I quite like it 🙂 One follow up question - can convention plugin defined in the

buildSrc

use alias from version catalog rather hardcoded id string?? `buildSrc\src\main\kotlin\local.testplugin.gradle.kts`: Does not work:

plugins {
    alias(libs.plugins.spotless)
}

Works:

plugins {
    id("com.diffplug.spotless")
}

No, unfortunately not. For outside the

plugins { ... }

block there is a hack-around I created in the according feature request. But within the

plugins { ... }

block it does not work.

I made most of this stuff work 🙂 I just have a single warning "The

embedded-kotlin

and

kotlin-dsl

plugins rely on features of Kotlin

1.8.10

that might work differently than in the requested version

1.8.20

." - any idea on how to solve this?

Kotlin-dsl uses the embedded Kotlin version (1.8.10) for plugin code. This shouldn’t be mixed with say Kotlin(jvm) which is for application code.