# Sharing build logic in a multi-repo setup with Test Suites (Incubating) Sample

version 7.5.1

- Groovy DSL

- Kotlin DSL

| You can open this sample inside an IDE using the IntelliJ native importer or Eclipse Buildship.

This sample shows how build logic can be organized into reusable pieces and published to a repository for reuse in other projects for multi-repo setups.

| This sample shows how to adopt an existing sample for use with Test Suites.

| Test Suites are an incubating feature, and the details described here may change.

## Use case

As an example, let’s say an organization produces two types of Java software - services and libraries. We want to apply a set of code quality checking rules to both types of projects and configure some aspects specific to each type.

## Organizing build logic

The use case can be modelled by layering three separate plugins:

Build logic layout

    ├── convention-plugins
    │   ├── build.gradle
    │   ├── settings.gradle
    │   ├── src
    │   │   ├── main
    │   │   │   └── groovy
    │   │   │       ├── com.myorg.java-conventions.gradle
    │   │   │       ├── com.myorg.library-conventions.gradle
    │   │   │       └── com.myorg.service-conventions.gradle
    ...

Build logic layout

    ├── convention-plugins
    │   ├── build.gradle.kts
    │   ├── settings.gradle.kts
    │   ├── src
    │   │   ├── main
    │   │   │   └── kotlin
    │   │   │       ├── com.myorg.java-conventions.gradle.kts
    │   │   │       ├── com.myorg.library-conventions.gradle.kts
    │   │   │       └── com.myorg.service-conventions.gradle.kts
    ...

- `com.myorg.java-conventions` - configures conventions that are generic for any Java project in the organization. This applies for both types of previously identified software and thus this plugin will be applied in both subsequent plugins.

- `com.myorg.library-conventions` - adds publishing configuration to publish to the organization’s repository and configures mandatory documentation checks.

- `com.myorg.service-conventions` - configures integration tests and checks for mandatory content in a README. Since services differ from libraries, different requirements for documentation are configured in this case.

All plugins created in this sample contain functional tests that use TestKit to verify their behavior.

## Compiling convention plugins

In this sample, convention plugins are implemented as precompiled script plugins - this is the simplest way to start out as you can use one of Gradle’s DSLs directly to implement the build logic, just as if the plugin was a regular build script.

In order for precompiled script plugins to be discovered, the `convention-plugins` project needs to apply the `groovy-gradle-plugin` plugin in its `build.gradle` file:

In order for precompiled script plugins to be discovered, the `convention-plugins` project needs to apply the `kotlin-dsl` plugin in its `build.gradle.kts` file:

Example 1. Enabling precompiled script plugins
convention-plugins/build.gradle

    plugins {
        id 'groovy-gradle-plugin'
    }

convention-plugins/build.gradle.kts

    plugins {
        `kotlin-dsl`
    }

## Publishing convention plugins

In this sample we are targeting a multi-repo setup. In order to apply the above plugins to separate projects, they have to be published to a company’s artifact repository. Convention plugins are regular Gradle plugins - thus they can be published to an external repository like any other Gradle plugin.

Here, we configure the project to publish the plugins using the maven-publish plugin. For demonstration purposes, we publish to a local filesystem directory. You can find information about how to publish to a remote repository in the repositories section of the maven-publish plugin.

Example 2. Publishing configuration
convention-plugins/build.gradle

    plugins {
        id 'groovy-gradle-plugin'
        id 'maven-publish'
        id 'java'
    }

    group = 'com.myorg.conventions'
    version = '1.0'

    publishing {
        repositories {
            maven {
                // change to point to your repo, e.g. http://my.org/repo
                url = layout.buildDirectory.dir("repo")
            }
        }
    }

    tasks.named('publish') {
        dependsOn('check')
    }

convention-plugins/build.gradle.kts

    plugins {
        `kotlin-dsl`
        `maven-publish`
    }

    group = "com.myorg.conventions"
    version = "1.0"

    publishing {
        repositories {
            maven {
                // change to point to your repo, e.g. http://my.org/repo
                url = uri(layout.buildDirectory.dir("repo"))
            }
        }
    }

    tasks.publish {
        dependsOn("check")
    }

The plugins can be published using:

    ./gradlew publish

In order to consume them in another project, configure the plugins repository in the settings file and apply the plugin:

settings.gradle

    pluginManagement {
        repositories {
            gradlePluginPortal()
            maven {
                // replace the path with the actual path to the repository
                url = uri('<path-to>/convention-plugins/build/repo')
            }
        }
    }

build.gradle

    plugins {
        id 'com.myorg.service-conventions' version '1.0'
    }

settings.gradle.kts

    pluginManagement {
        repositories {
            gradlePluginPortal()
            maven {
                // replace the path with the actual path to the repository
                url = uri("<path-to>/convention-plugins/build/repo")
            }
        }
    }

build.gradle.kts

    plugins {
        id("com.myorg.service-conventions") version "1.0"
    }

## Things to note

### Applying an external plugin in convention plugin

The `com.myorg.java-conventions` plugin uses the SpotBugs plugin to perform static code analysis.

SpotBugs is an external plugin - external plugins need to be added as implementation dependencies before they can be applied in a convention plugin:

convention-plugins/build.gradle

    repositories {
        gradlePluginPortal() // so that external plugins can be resolved in dependencies section
    }

    dependencies {
        implementation 'gradle.plugin.com.github.spotbugs.snom:spotbugs-gradle-plugin:4.7.2'
    }

convention-plugins/build.gradle.kts

    repositories {
        gradlePluginPortal() // so that external plugins can be resolved in dependencies section
    }

    dependencies {
        implementation("gradle.plugin.com.github.spotbugs.snom:spotbugs-gradle-plugin:4.7.2")
    }

- The dependency artifact coordinates (GAV) for a plugin can be different from the plugin id.

- The Gradle Plugin Portal (`gradlePluginPortal()`) is added as a repository for plugin dependencies.

- The plugin version is determined from the dependency version.

Once the dependency is added, the external plugin can be applied in a convention plugin by id:

convention-plugins/src/main/groovy/com.myorg.java-conventions.gradle

    plugins {
        id 'java'
        id 'checkstyle'

        // NOTE: external plugin version is specified in implementation dependency artifact of the project's build file
        id 'com.github.spotbugs'
    }

convention-plugins/src/main/kotlin/com.myorg.java-conventions.gradle.kts

    plugins {
        java
        checkstyle

        // NOTE: external plugin version is specified in implementation dependency artifact of the project's build file
        id("com.github.spotbugs")
    }

### Applying other convention plugins

Convention plugins can apply other convention plugins.

The `com.myorg.library-conventions` and `com.myorg.service-conventions` plugins both apply the `com.myorg.java-conventions` plugin:

convention-plugins/src/main/groovy/com.myorg.library-conventions.gradle

    plugins {
        id 'java-library'
        id 'maven-publish'
        id 'com.myorg.java-conventions'
    }

convention-plugins/src/main/groovy/com.myorg.service-conventions.gradle

    plugins {
        id 'com.myorg.java-conventions'
    }

convention-plugins/src/main/kotlin/com.myorg.library-conventions.gradle.kts

    plugins {
        `java-library`
        `maven-publish`
        id("com.myorg.java-conventions")
    }

convention-plugins/src/main/kotlin/com.myorg.service-conventions.gradle.kts

    plugins {
        id("com.myorg.java-conventions")
    }

### Using classes from the main source set

Convention plugins can use classes defined in the main source set of the plugins project.

In this sample, `com.myorg.service-conventions` plugin uses a custom task class from `src/main/java` to configure service README checks:

convention-plugins/src/main/groovy/com.myorg.service-conventions.gradle

    def readmeCheck = tasks.register('readmeCheck', com.example.ReadmeVerificationTask) {
        // Expect the README in the project directory
        readme = layout.projectDirectory.file("README.md")
        // README must contain a Service API header
        readmePatterns = ['^## Service API$']
    }

convention-plugins/src/main/kotlin/com.myorg.service-conventions.gradle.kts

    val readmeCheck by tasks.registering(com.example.ReadmeVerificationTask::class) {
        readme.set(layout.projectDirectory.file("README.md"))
        readmePatterns.set(listOf("^## Service API$"))
    }

For more details on authoring custom Gradle plugins, consult the user manual.