Конфигурация проекта шаблона в Gradle с Gradle Kotlin DSL

в настоящее время я пытаюсь улучшить то, как наши проекты делятся своей конфигурацией. У нас есть много различных многомодульных проектов gradle для всех наших библиотек и микросервисов (т. е. многих репозиториев git).

мои основные цели:

• чтобы моя конфигурация репозитория Nexus не дублировалась в каждом проекте (кроме того, я могу с уверенностью предположить, что URL-адрес не изменится)
• чтобы сделать мои пользовательские плагины Gradle (опубликованные в Nexus) доступными для каждого проект с минимальным шаблоном / дублированием (они должны быть доступны для каждого проекта, и единственное, что заботит проект, - это версия, которую он использует)
• никакой магии-разработчикам должно быть очевидно, как все настроено

мое текущее решение-это пользовательский дистрибутив gradle со скриптом init, который:

• добавляет mavenLocal() и наш репозиторий Nexus для репозиториев проекта (очень похож на Gradle сценарий инициализации пример документации, за исключением того, что он добавляет РЕПО, а также проверяет их)
• настраивает расширение, которое позволяет добавлять плагины gradle в путь к классам buildscript (используя этот способ). Он также добавляет наше РЕПО Nexus в качестве РЕПО buildscript, поскольку именно там размещаются Плагины. У нас есть довольно много плагинов (построенных на отличном Netflix туманность Плагины) для различных boilerplate: стандартная установка проекта (установка kotlin, Установка испытания, etc), выпуск, публикация, документация и т. д. И это означает наш проект build.gradle файлы только для зависимостей.

вот сценарий инициализации (санируется):

/**
 * 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
                }
            }
        }

    }

}

затем я настраиваю каждый новый проект, добавляя следующее в корневую сборку.файл gradle:

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'
    }
}

пока этот подход работает, позволяет воспроизводимые сборки (в отличие от нашей предыдущей установки, которая применяла скрипт сборки из URL - адреса, который в то время не был кэшируемым), и позволяет работать в автономном режиме, это делает его немного волшебным, и мне было интересно, могу ли я делать вещи лучше.

все это было вызвано чтением комментарий к Github по Gradle dev Stefan Oehme заявив, что сборка должна работать, не полагаясь на сценарий init, т. е. сценарии init должны быть просто декоративными и делать такие вещи, как документированный пример - предотвращение несанкционированных репозиториев и т. д.

моя идея состояла в том, чтобы написать некоторые функции расширения, которые позвольте мне добавить наше РЕПО Nexus и плагины в сборку таким образом, чтобы они выглядели так, как будто они были встроены в gradle (подобно функциям расширения gradleScriptKotlin() и kotlin-dsl() предоставлено Gradle Kotlin DSL.

поэтому я создал свои функции расширения в проекте Kotlin gradle:

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"
}

с планом использовать их в моем проекте build.gradle.kts следующим образом:

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

buildscript {

    repositories {
        corporateNexus()
    }

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

однако Gradle не смог увидеть мои функции при использовании в buildscript block (невозможно скомпилировать скрипт). Использование их в обычных репозиториях/зависимостях проекта работало нормально (они видны и работают, как ожидалось).

если это сработало, я надеялся связать банку с моим пользовательским дистрибутивом, то есть мой скрипт init мог просто выполнить простую проверку, а не скрывать магический плагин и конфигурацию РЕПО. Функции расширения не нужно будет изменять, так что это не потребует выпуска нового распределения Gradle, когда Плагины меняются.

что я пробовал:

• добавление моего jar в путь к классам buildscript тестового проекта (т. е. buildscript.dependencies) - не работает (возможно, это не работает по дизайну, поскольку кажется неправильным добавлять зависимость к buildscript это упоминается в том же блоке)
• ввод функций в buildSrc (который работает для обычных проектов deps / repos, но не buildscript, но это не реальное решение, поскольку оно просто перемещает boilerplate)
• роняя банку в распределение

так что мой вопрос действительно сводится к:

• это то, что я пытаюсь достичь (возможно ли сделать пользовательские классы/функции видимыми для buildScript блок)?
• есть ли лучший подход к настройке корпоративного РЕПО Nexus и созданию пользовательских плагинов (опубликованных в Nexus), доступных во многих отдельных проектах (т. е. полностью различные кодовые базы) с минимальной конфигурацией шаблона?