Image taken from the Internet

In this article I’d like to describe how you can get rid of boilerplate code in your build.gradle files in multimodule project with the help of the Convention plugins.

TL;DR — with the help of convention plugins you can refactor your Gradle file from this state (71 lines):

To this (15 lines):

Interested? Before diving into the refactoring let me discuss the initial setup I have. I have a KMP library that can launch the in-app review in various Android and iOS stores. Since some stores implementations require additional SDKs I decided to make them as separate modules. So, the library contains multiple modules that have the same structure:

1. Artifact group + version for building and publishing the module
2. Targets setup
3. Java setup
4. Dependencies setup
5. Android setup
6. Publishing setup
7. Wrapper task for building and publishing

Everything except the 4th point is the same across the modules, so we can extract it into the Convention Plugin. Probably, it’s a default Gradle Plugin that contains some “conventional setup” for some part of the logic in the .gradle file.

To start the implementation we need to create the module for the plugin. Gradle documentation advises us to implement composite-build for this case, so let’s do it. Declare a folder and name it in any way you want (it’s a common practice to name it build-logic). To make this project a subproject we need to add settings.gradle.kts file where the subproject’s structure will be described. Here’s the way how it looks like:

There are repositories declared in this file that contain the dependencies used inside the subproject, specified path to the version catalog and included the module (convention) where the plugin is located.

Don’t forget to add the subproject into the main project — put the line includeBuild(“build-logic”) inside the pluginManagement block inside the root’s settings.gradle.kts.

Now let’s move to the module with the plugin. Here’s it’s build.gradle file:

Plugin kotlin-dsl is applied to this module as it contains an extension to register the convention plugin we are going to implement. Then we register the convention plugin (specify it’s name, id, implementation class) and apply dependencies we need for the development of plugin. Since the plugin is used only during the compile time we declare the dependencies as compileOnly.

The implementation of the plugin is the following:

The new plugin should be a subclass of the Project. And inside the body of the apply method we add all the logic we need. So, as you can see here we apply default plugins, setup targets, Java and Android, publishing and even create a new task.

I want to highlight that it’s more convenient to create extensions to get the pluginId/version you need from the version catalog. This is the way how these extensions look like:

After everything is done we just add the plugin into the modules we need and cleanup the duplicated code from the build.gradle file since this logic is encapsulated inside the plugin:

The full implementation can be found inside the project.

Thank you for reading! Feel free to ask questions and leave the feedback in comments or Linkedin.