This message was deleted.

buildSrc generates accessors so you don't have to remember the ID

What accessors? For extensions? e.g. like applying

id(kotlin("jvm"))

gives you

kotlin {}

accessor?

Well, Gradle also generate accessors for plugins from included build or normal binary plugins, like

kotlin { ... }

you mentioned. IIRC they are generated based on registering extension no matter how exactly plugin in written. Also for

org.example.my-plugin.gradle.kts

in either

buildSrc

or included build gradle would generate accessor so you can apply it using `plugins { org.example.\`my-plugin\` }` in

build.gradle.kts

as well as via

plugins { id("org.example.my-plugin") }

. I avoid using former variant (using accessors) since IDEA has bad habit to either insert imports for generated accessors or just break a build at inconvenient time. Term convention plugin is a bit a confusing one since some call precompiled script plugins that. As I understand plugin should be called convention plugin if it configures some defaults/conventions for your build. For example apply

java-library

plugin, configure target java version, configure publication etc. And it can be written as plain java/groovy/kotlin binary plugin or kotlin/groovy precompiled script plugin.

Yeah, my question is basically putting

my.plugin.gradle.kts

in either

buildSrc

or included build from

my-convention-plugins-module

If the file is named

some-plugin.gradle.kts

, you can apply it via

plugins {
    `some-plugin` // same as id("some-plugin")
}

Didn't know that, but I'm not really concerned about those kind of accessors all that much.

I can't find it, hope he can share it here soon

Also for 

org.example.my-plugin.gradle.kts

 in either 

buildSrc

 or included build gradle would generate accessor so you can apply it using `plugins { org.example.\`my-plugin\` }` in 

build.gradle.kts

 as well as via 

plugins { id("org.example.my-plugin") }

.

That's exactly not true. That's one of the differences of

buildSrc

vs. included build. With

buildSrc

you get the accessors for doing `plugins { org.example.

my-plugin

}`, with included builds you don't. The other slight differences are usually more on the positive side.

buildSrc

is always executed before your build whether you use something or not, its tests task is also always exectued (except if it is up-to-date of course), and the whole result is prepended to all build scripts of the main build. The included build is only executed if actually used. It is only added to the build script class paths where it actually is used and only the necessary work (no tests) is done to get the jar you need at that situation. If you want the tests to be executed, you can wire them to your main builds

check

task for example.

Included build is better in terms of performance, it would only build required jars instead of also running tests (even with up-to-date checks it takes some time). Also you could use included build from several build but

buildSrc

could be used only from one build