gradle - 根据配置阶段完成后确定的模式复制文件

Question

我目前正在评估 gradle 作为 Maven 的替代方案，用于基于 ant+ivy 构建的本土约定。 ant+ivy 构建旨在为广泛的 j2se 应用程序提供标准环境，它支持以下常规布局到应用程序配置

conf/
    fooPROD.properties
    fooUAT.properties
    bar.properties
    UK/
        bazPROD.properties
        bazUAT.properties

如果我选择为 UAT 构建，那么我会得到

conf/
    foo.properties
    bar.properties
    UK/
        baz.properties

即它复制以目标环境(在这种情况下为 UAT)为后缀的文件以及没有这种模式的任何文件。除此之外，还会发生许多其他事情，使其变得更加复杂，但这是我当前问题的核心。

我一直在玩转各种 gradle 功能，同时转录它，而不是让它工作。我目前的方法是允许像这样动态提供 targetenv

tasks.addRule("Pattern: make<ID>") { String taskName ->
    task(taskName).dependsOn tasks['make']
}

make 任务处理 conf 文件从 src 到构建区域的各种复制/过滤/转换。为此，它必须弄清楚在创建 DAG 后我当前正在做什么的 targetenv

gradle.taskGraph.whenReady {taskGraph ->
    def makeTasks = taskGraph.getAllTasks().findAll{ 
        it.name.startsWith('make') && it.name != 'make' 
    }
    if (makeTasks.size() == 1) {
        project.targetEnv = makeTasks[0].name - 'make'
    } else {
        // TODO work out how to support building n configs at once
    }
}

(感觉必须有一种更快/更惯用的方法来做到这一点，但我离题了)

然后我可以像 gradle makeUAT 一样运行它

我的问题是设置 targetEnv这种方式意味着 targetEnv未在配置时设置。因此，如果我有一个复制任务，比如

task prepareEnvSpecificDist(type: Copy) {
    from 'src/main/conf'
    into "$buildDir/conf"
    include "**/*$project.targetEnv.*"
    rename "(.*)$project.targetEnv.(.*)", '$1.$2'
}

它不符合我的要求，因为 $project.targetEnv还没有设置。天真地，我把它改成了

task prepareEnvSpecificDist(type: Copy) << {
    from 'src/main/conf'
    into "$buildDir/conf"
    include "**/*$project.targetEnv.*"
    rename "(.*)$project.targetEnv.(.*)", '$1.$2'
}

一旦我明白发生了什么。然后这失败了

Skipping task ':prepareEnvSpecificDist' as it has no source files.

因为我还没有配置复制任务来告诉它输入和输出是什么。

问题是如何处理基于配置完成后变得具体的属性的任务配置问题？

注意:我意识到我可以传入系统属性并执行类似 gradle -Dtarget.env=UAT make 的操作但这相对冗长，我想弄清楚到底发生了什么。

干杯

马特

Answer 1

为特定目标环境构建是一个跨领域问题，并不真正适合任务的性质。使用系统属性 ( -D ) 或项目属性 ( -P ) 是处理此问题的自然方式。

如果你绝对想保存几个字符，你可以查询和操作gradle.startParameter.taskNames实现一个看起来像任务名称的环境切换。然而，这是一个非标准的解决方案。

How does one deal with the problem of task configuration based on properties that become concrete after configuration has completed?

这是更普遍的问题的一个特例，即配置值在被读取后被写入。典型的解决方案是:

如果可以的话，避免它。

一些任务/模型属性接受一个闭包，然后会被延迟评估。这需要在相应的任务/插件文档中查找。

在全局 Hook 中执行配置，如 gradle.projectsEvaluated或 gradle.taskGraph.whenReady (取决于具体需要)。

在任务操作中执行配置(在执行时)。正如您已经体验过的那样，这并非在所有情况下都有效，并且通常不鼓励(但有时可以容忍)。

插件使用 convention mapping懒惰地将模型值绑定(bind)到任务属性。这是一种不应该在构建脚本中使用的高级技术，但对于编写扩展构建语言的插件是必需的。

作为旁注，请记住 Gradle 允许您引入自己的抽象。例如，您可以添加一个允许您编写的方法:

environment("uat") {
    // special configuration for UAT environment
}