Boilerplate-Projektkonfiguration in Gradle mit Gradle Kotlin DSL

Ich versuche derzeit, die Art und Weise zu verbessern, wie unsere Projekte ihre Konfiguration freigeben. Wir haben viele verschiedene Multi-Modul-Gradle-Projekte für alle unsere Bibliotheken und Microservices (d. H. Viele Git-Repos). 

Meine Hauptziele sind:

• Damit meine Nexus-Repository-Konfiguration nicht in jedem Projekt dupliziert wird (ich kann auch davon ausgehen, dass sich die URL nicht ändert)
• Um meine benutzerdefinierten Gradle-Plugins (für Nexus veröffentlicht) für jedes Projekt mit minimalem Speicherplatz/Duplizierung verfügbar zu machen (sie sollten für jedes Projekt verfügbar sein, und das einzige, was das Projekt interessiert, ist die Version, die es verwendet).
• Keine Magie - es sollte für die Entwickler offensichtlich sein, wie alles konfiguriert ist

Meine derzeitige Lösung ist eine benutzerdefinierte Gradel-Distribution mit einem Init-Skript, das:

• fügt mavenLocal() und unser Nexus-Repository zu den Projekt-Repos hinzu (sehr ähnlich dem Skript-Dokumentationsbeispiel von Gradle init , außer dass Repos hinzugefügt und validiert werden).
• konfiguriert eine Erweiterung, mit der unsere Gradle-Plugins zum Buildscript-Klassenpfad hinzugefügt werden können (mithilfe von dieser Problemumgehung ). Außerdem wird unser Nexus-Repo als Buildscript-Repo hinzugefügt, da dort die Plugins gehostet werden. Wir haben einige Plugins (aufbauend auf Netflix 'exzellenten nebula plugins ) für verschiedene Boilerplates: Standard-Projekt-Setup (Kotlin-Setup, Test-Setup usw.), Veröffentlichung, Veröffentlichung, Dokumentation usw. Dies bedeutet, dass unsere Projektdateien build.gradle sind so ziemlich nur für Abhängigkeiten.

Hier ist das Init-Skript (bereinigt):

/**
 * Gradle extension applied to all projects to allow automatic configuration of Corporate plugins.
 */
class CorporatePlugins {

    public static final String NEXUS_URL = "https://example.com/repository/maven-public"
    public static final String CORPORATE_PLUGINS = "com.example:corporate-gradle-plugins"

    def buildscript

    CorporatePlugins(buildscript) {
        this.buildscript = buildscript
    }

    void version(String corporatePluginsVersion) {
        buildscript.repositories {
            maven {
                url NEXUS_URL
            }
        }
        buildscript.dependencies {
            classpath "$CORPORATE_PLUGINS:$corporatePluginsVersion"
        }
    }

}

allprojects {
    extensions.create('corporatePlugins', CorporatePlugins, buildscript)
}

apply plugin: CorporateInitPlugin

class CorporateInitPlugin implements Plugin<Gradle> {

    void apply(Gradle gradle) {

        gradle.allprojects { project ->

            project.repositories {
                all { ArtifactRepository repo ->
                    if (!(repo instanceof MavenArtifactRepository)) {
                        project.logger.warn "Non-maven repository ${repo.name} detected in project ${project.name}. What are you doing???"
                    } else if(repo.url.toString() == CorporatePlugins.NEXUS_URL || repo.name == "MavenLocal") {
                        // Nexus and local maven are good!
                    } else if (repo.name.startsWith("MavenLocal") && repo.url.toString().startsWith("file:")){
                        // Duplicate local maven - remove it!
                        project.logger.warn("Duplicate mavenLocal() repo detected in project ${project.name} - the corporate gradle distribution has already configured it, so you should remove this!")
                        remove repo
                    } else {
                        project.logger.warn "External repository ${repo.url} detected in project ${project.name}. You should only be using Nexus!"
                    }
                }

                mavenLocal()

                // define Nexus repo for downloads
                maven {
                    name "CorporateNexus"
                    url CorporatePlugins.NEXUS_URL
                }
            }
        }

    }

}

Dann konfiguriere ich jedes neue Projekt, indem ich der root-Datei build.gradle Folgendes hinzufügen:

buildscript {
    // makes our plugins (and any others in Nexus) available to all build scripts in the project
    allprojects {
        corporatePlugins.version "1.2.3"
    }
}

allprojects  {
    // apply plugins relevant to all projects (other plugins are applied where required)
    apply plugin: 'corporate.project'

    group = 'com.example'

    // allows quickly updating the wrapper for our custom distribution
    task wrapper(type: Wrapper) {
        distributionUrl = 'https://com.example/repository/maven-public/com/example/corporate-gradle/3.5/corporate-gradle-3.5.Zip'
    }
}

Dieser Ansatz funktioniert zwar und ermöglicht reproduzierbare Builds (im Gegensatz zu unserem vorherigen Setup, bei dem ein Buildskript von einer URL angewendet wurde - was zu dieser Zeit nicht im Cache abgelegt werden konnte), und das Offline-Arbeiten ermöglicht wird. Es macht es jedoch etwas magisch, und ich frage mich, ob ich könnte die Dinge besser machen. 

Dies wurde alles durch das Lesen von einem Kommentar zu Github von Gradle-Entwickler Stefan Oehme ausgelöst, der besagt, dass ein Build funktionieren sollte, ohne auf ein Init-Skript angewiesen zu sein. Dh Init-Skripts sollten nur dekorativ sein und Dinge wie das dokumentierte Beispiel tun, um nicht autorisierte Repos zu verhindern , usw.

Meine Idee war, einige Erweiterungsfunktionen zu schreiben, die es mir ermöglichen, unser Nexus-Repo und unsere Plugins zu einem Build hinzuzufügen, das aussah, als wären sie in Gradle eingebaut (ähnlich wie die Erweiterungsfunktionen gradleScriptKotlin() und kotlin-dsl() bereitgestellt von der Gradle Kotlin DSL.

Also habe ich meine Erweiterungsfunktionen in einem Kotlin Gradle-Projekt erstellt:

package com.example

import org.gradle.api.artifacts.dsl.DependencyHandler
import org.gradle.api.artifacts.dsl.RepositoryHandler
import org.gradle.api.artifacts.repositories.MavenArtifactRepository

fun RepositoryHandler.corporateNexus(): MavenArtifactRepository {
    return maven {
        with(it) {
            name = "Nexus"
            setUrl("https://example.com/repository/maven-public")
        }
    }
}

fun DependencyHandler.corporatePlugins(version: String) : Any {
    return "com.example:corporate-gradle-plugins:$version"
}

Mit dem Plan, sie in build.gradle.kts meines Projekts wie folgt zu verwenden:

import com.example.corporateNexus
import com.example.corporatePlugins

buildscript {

    repositories {
        corporateNexus()
    }

    dependencies {
        classpath(corporatePlugins(version = "1.2.3"))
    }
}

Gradle konnte meine Funktionen jedoch nicht sehen, wenn sie im buildscript-Block verwendet wurden (Skript konnte nicht kompiliert werden). Ihre Verwendung in den normalen Projekt-Repos/Abhängigkeiten funktionierte jedoch gut (sie sind sichtbar und funktionieren wie erwartet). 

Wenn dies funktionierte, hoffte ich, die Dose in meine benutzerdefinierte Distribution zu bündeln. Das heißt, mein Init-Skript könnte einfach eine einfache Überprüfung durchführen, anstatt die magische Plugin- und Repo-Konfiguration zu verstecken. Die Erweiterungsfunktionen müssen nicht geändert werden, sodass keine neue Gradle-Distribution freigegeben werden muss, wenn Plugins geändert werden.

Was ich probiert habe:

• hinzufügen meines Jars zum Buildscript-Klassenpfad des Testprojekts (d. h. buildscript.dependencies) - funktioniert nicht (möglicherweise funktioniert das nicht konstruktiv, da es nicht richtig erscheint, buildscript eine Abhängigkeit hinzuzufügen, auf die im selben Block verwiesen wird).
• die Funktionen in buildSrc setzen (was für normale Projekt-Deps/Repos aber nicht für buildscript geeignet ist, aber keine echte Lösung ist, da nur die Speicherplatte verschoben wird)
• das jar im lib-Ordner der Distribution ablegen

Meine Frage lautet also:

• Ist das, was ich zu erreichen versuche, möglich (können benutzerdefinierte Klassen/Funktionen für den buildScript-Block sichtbar gemacht werden)? 
• Gibt es einen besseren Ansatz für die Konfiguration eines Nexus-Repos für Unternehmen und das Bereitstellen von benutzerdefinierten Plugins (für Nexus veröffentlicht) für viele separate Projekte (d. H. Völlig unterschiedliche Codebases) mit minimaler Boilerplate-Konfiguration?