hello, I'm trying to figure out the best way to structure a custom plugin within a multi-module project. Specifically, I have a plugin I want to share with other sub-projects, and I'm likely gonna add more in the future. Also, this plugin has dependencies, and if I add more plugins later they might not share these dependencies. Right now the plugin is inside a

buildSrc

folder, but it's not a convention plugin (i.e. it's declared using the gradle plugin development plugin). This works but if I declare dependencies inside the

buildSrc/build.gradle.kts

file then afaiu these dependencies are shared across all plugins I'd declare there. What's the best approach here? Move the plugin to its own separate subproject (and if so, how do I then make it available to the rest of the build as a plugin)? Or rather convert to a convention plugin (in which case, can I then declare and reference classes declared outside the convention build script)? Any suggestions?

I guess you mix up the terms convention plugin and precompiled script plugin. Convention plugin is any plugin that employs your conventions, no matter how it is implemented. A precompiled script plugin can be a convention plugin or also any other type of plugin, it is just the syntactic sugar to write a plugin DSL-y. Yes, if you have mutliple plugins in one project, they share all dependencies. Using a precompiled script plugin or not changes absolutely nothing in that regards also for those you declare your dependencies in your plugin build build script. You can of course split your plugin build in multiple projects or even multiple builds if you use composite builds, instead of

buildSrc

. Then you can properly separate your plugins and their dependencies. If they are still in

buildSrc

you have better structure in your sources, but at runtime still all will be one big bunch as the whole

buildSrc

result is prepended to the build script classpaths. If you use composite build instead, the plugins are more like usual and only are built when used and only in the classpaths where you use them / add them.

@Vampire thanks that clear things up somehow. Two more questions. Let's imagine I move this plugin to it's own

plugins/python

folder: • how do I make it available as a plugin to the rest of the build? afaik the

buildSrc

trick does it for you but if it's just another subproject it needs to be available to the build and not the project being built • sort of unrelated, but is there a way to tell gradle to import "all projects inside a folder"? In this case, if I have multiple plugins, is there a way to have just one declaration in

settings.gradle.kts

instead of one per plugin? (more of a bikeshedding thing this one, really)

how do I make it available as a plugin to the rest of the build?

What do you mean with "folder"? Do you mean an own project in your build? Do you mean an own build? Do you mean anything else? If the first, then you cannot use it in the same build, that would be chicken-and-egg. If the second, the term you want to look up in the userguide is "composite build". If the third, ... well ...

but is there a way to tell gradle to import "all projects inside a folder"?

You have a programming language at hand, just list the directory, and include all if you really want that. Or look for a plugin that does it for you, I guess there are some out there.

I mean I’d like this plugin to live as its own “thing” inside my monorepo. And if I’m reading the documentation correctly, it seems I could mix composite builds and multi-project inside the same global project, is that right? Meaning, in the same settings file I can have both include and includeBuild statements

you can

includeBuild

a project with subprojects, e.g.

// settings.gradle.kts
pluginManagement {
    includeBuild("plugins")
}

// plugins/settings.gradle.kts
include(":foo")
include(":bar")

then

:plugins:foo

and

:plugins:bar

can declare plugins that can be used in

:

build

Ok great, thanks for confirming that!