Gradle with Gradle Kotlin DSL中的Boilerplate项目配置

Question

我目前正在努力改进项目共享配置的方式.我们为所有库和微服务(即许多git repos)提供了许多不同的多模块gradle项目.

我的主要目标是:

• 不要在每个项目中复制我的Nexus存储库配置(同样,我可以放心地假设URL不会更改)
• 为了使我的自定义Gradle插件(发布到Nexus)可用于每个项目,只需极少的样板/复制(它们应该可用于每个项目,项目唯一关心的是它使用的版本)
• 没有魔力 - 开发人员应该明白如何配置所有内容

我目前的解决方案是使用init脚本的自定义gradle分发:

• 添加mavenLocal()和我们的Nexus存储库到项目repos(非常类似于Gradle init脚本文档示例,除了它添加repos以及验证它们)
• 配置一个扩展,允许我们的gradle插件添加到buildscript类路径(使用此解决方法).它还添加了我们的Nexus repo作为buildcript repo,因为它是托管插件的地方.我们有很多插件(基于Netflix优秀的星云插件)用于各种样板:标准项目设置(kotlin设置,测试设置等),发布,发布,文档等,这意味着我们的项目build.gradle文件几乎只用于依赖.

这是init脚本(已清理):

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

    }

}

然后我通过将以下内容添加到根build.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应用了构建脚本 - 当时不可缓存),并允许脱机工作,它确实使它有点神奇,我想知道我是否可以做得更好.

这一切都是通过阅读Gradle dev Stefan Oehme 对Github的评论引发的,说明构建应该不依赖于init脚本,即init脚本应该是装饰性的并且做一些类似于记录的示例 - 防止未经授权的回购等.

我的想法是写一些扩展功能,让我对我们的Nexus回购和插件添加到构建的方式,看起来好像他们是建成gradle这个(类似扩展函数gradleScriptKotlin()和kotlin-dsl()由摇篮科特林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块中使用时无法看到我的函数(无法编译脚本).在正常的项目repos/dependencies中使用它们工作正常(它们是可见的并按预期工作).

如果这有效,我希望将jar捆绑到我的自定义发行版中,这意味着我的init脚本可以只进行简单的验证,而不是隐藏神奇的插件和repo配置.扩展函数不需要更改,因此在插件更改时不需要释放新的Gradle分布.

我尝试了什么:

• 将我的jar添加到测试项目的buildscript类路径(即buildscript.dependencies) - 不起作用(可能这在设计上不起作用,因为buildscript在同一块中引用的依赖项似乎不正确)
• 将函数放入buildSrc(适用于普通的项目deps/repos但不是buildscript,但不是真正的解决方案,因为它只是移动样板)
• 将jar放在发行版的lib文件夹中

所以我的问题归结为:

• 我正在尝试实现的是什么(是否可以使buildScript块可见的自定义类/函数)？
• 是否有更好的方法来配置企业Nexus仓库并使用最少的样板配置在许多单独的项目(即完全不同的代码库)中提供自定义插件(发布到Nexus)？

Answer 1

如果您想从所有Gradle Kotlin DSL中获益,您应该努力使用该plugins {}块应用所有插件.请参阅https://github.com/gradle/kotlin-dsl/blob/master/doc/getting-started/Configuring-Plugins.md

您可以在设置文件中管理插件存储库和解决方案策略(例如,他们的版本).从Gradle 4.4开始,可以使用Kotlin DSL编写此文件settings.gradle.kts.请参阅https://docs.gradle.org/4.4-rc-1/release-notes.html.

考虑到这一点,您可以拥有一个集中的Settings脚本插件,可以设置并在构建settings.gradle.kts文件中应用它:

// corporate-settings.gradle.kts
pluginManagement {
    repositories {
        maven {
            name = "Corporate Nexus"
            url = uri("https://example.com/repository/maven-public")
        }
        gradlePluginPortal()
    }
}

和:

// settings.gradle.kts
apply(from = "https://url.to/corporate-settings.gradle.kts")

然后在项目构建脚本中,您只需从公司存储库中请求插件:

// build.gradle.kts
plugins {
    id("my-corporate-plugin") version "1.2.3"
}

如果您希望项目在多项目构建中构建脚本以不重复插件版本,则可以通过在根项目中声明版本来使用Gradle 4.3执行此操作.请注意,您也可以将它的版本中settings.gradle.kts使用pluginManagement.resolutionStrategy,如果让所有建立使用相同的插件版本是你所需要的.

另请注意,要使所有这些工作正常,必须使用插件标记工件发布插件.这可以通过使用java-gradle-plugin插件轻松完成.

Answer 2

我向@eskatos 承诺我会回来并就他的回答提供反馈 - 所以它来了！

我的最终解决方案包括：

• 每个项目的 Gradle 4.7 包装器（指向Nexus中http://services.gradle.org/distributions设置的镜像作为原始代理存储库，即它是 vanilla Gradle，但通过 Nexus 下载）
• 发布到我们的 Nexus 存储库的自定义 Gradle 插件以及插件标记（由Java Gradle 插件开发插件生成）
• 在我们的 Nexus 存储库中镜像 Gradle 插件门户（即指向https://plugins.gradle.org/m2的代理存储库）
• settings.gradle.kts每个项目的一个文件，用于将我们的 maven 存储库和 gradle 插件门户镜像（均在 Nexus 中）配置为插件管理存储库。

该settings.gradle.kts文件包含以下内容：

pluginManagement {
    repositories {
        // local maven to facilitate easy testing of our plugins
        mavenLocal()

        // our plugins and their markers are now available via Nexus
        maven {
            name = "CorporateNexus"
            url = uri("https://nexus.example.com/repository/maven-public")
        }

        // all external gradle plugins are now mirrored via Nexus
        maven {
            name = "Gradle Plugin Portal"
            url = uri("https://nexus.example.com/repository/gradle-plugin-portal")
        }
    }
}

这意味着所有插件及其依赖项现在都通过 Nexus 代理，并且 Gradle 将通过 id 找到我们的插件，因为插件标记也发布到 Nexus。有mavenLocal在那里也有利于当地的我们的插件改变简单的测试。

每个项目的根build.gradle.kts文件然后按如下方式应用插件：

plugins {
    // plugin markers for our custom plugins allow us to apply our
    // plugins by id as if they were hosted in gradle plugin portal
    val corporatePluginsVersion = "1.2.3"
    id("corporate-project") version corporatePluginsVersion
    // 'apply false` means this plugin can be applied in a subproject
    // without having to specify the version again
    id("corporate-publishing") version corporatePluginsVersion apply false
    // and so on...
}

并配置 gradle 包装器以使用我们的镜像发行版，当与上述结合使用时，意味着所有内容（gradle、插件、依赖项）都来自 Nexus）：

tasks {
    "wrapper"(Wrapper::class) {
        distributionUrl = "https://nexus.example.com/repository/gradle-distributions/gradle-4.7-bin.zip"
    }
}

我希望使用@eskatos 的建议避免设置文件中的样板文件，即从settings.gradle.kts. IE

apply { from("https://nexus.example.com/repository/maven-public/com/example/gradle/corporate-settings/1.2.3/corporate-settings-1.2.3.kts" }

我什至设法生成了一个模板化脚本（与我们的插件一起发布）：

• 配置插件仓库（如上面的设置脚本）
• 如果请求的插件 id 是我们的插件之一并且未提供版本，则使用解析策略来应用与脚本关联的插件的版本（因此您可以通过 id 应用它们）

然而，即使它删除了样板，这意味着我们的构建依赖于与我们的 Nexus 存储库的连接，因为似乎即使从 URL 应用的脚本被缓存，Gradle 还是会执行 HEAD 请求来检查更改。在本地测试插件更改也很烦人，因为我必须手动将其指向本地 maven 目录中的脚本。使用我当前的配置，我可以简单地将插件发布到 Maven 本地并更新我项目中的版本。

我对当前的设置非常满意 - 我认为现在开发人员更清楚如何应用插件。由于两者之间没有依赖关系（并且不需要自定义 gradle 发行版），因此独立升级 Gradle 和我们的插件变得更加容易。