从 gradle 扩展访问配置闭包答案

【问题标题】：Accessing the configure closure from a gradle extension从 gradle 扩展访问配置闭包
【发布时间】：2013-06-28 08:35:36
【问题描述】：

我正在编写一个插件，其中执行如下操作：

project.extensions.create('myExtension', new MyExtension(project))

MyExtension 是定义我的新功能的类。

现在，在gradle.build 我可以这样做：

myExtension {
    // configure cool stuff
}

我现在想做的是“使用”这个 configure 闭包中的一些东西，然后使用 project.configure(myTask, closure) 将闭包的其余部分按原样传递给我定义的任务。但是，我不知道该怎么做

从MyExtension 类访问配置闭包。
“消耗”一些闭包，即访问闭包上的一些属性，然后剥离它们，留下另一个闭包，其中包含所有未触及的东西，但没有其他任何东西

任何指针将不胜感激 =)

【问题讨论】：

标签： plugins gradle

【解决方案1】：

这不是扩展的工作方式。立即评估闭包以配置扩展对象。在那之后，关闭就消失了。通常，插件将使用（包含在）扩展对象中的信息来进一步配置任务。

PS：这是extensions.create('myExtension', MyExtension, project)，而不是project.extensions.create('myExtension', new MyExtension(project))。

【讨论】：

好的。但是你会推荐什么方式来实现我的目标？该扩展将配置一个复制任务（或者更确切地说是一个从Copy 继承的自定义任务），但也会做一些其他的事情，我想避免为配置Copy 操作的每一种方式实现包装器。扩展是否应该扩展Copy？这有意义吗？
没有更多上下文很难说，但配置Copy 任务和做一些其他的事情可能不是要走的路。扩展意味着比任务更高级别的抽象，涵盖了 80% 的情况。一般不建议继承 Gradle 任务类；相反，自定义任务类应公开其自己的 API，并在必要时委托到 project.copy 方法。或者，自定义插件可以同时带来 Copy 任务和自定义任务，并使一个依赖于另一个。
好的，一些上下文：我想做的只是一个更可定制的发布插件，它处理版本编号并决定在发布时从哪里复制构建输出。在撰写此评论时，我意识到包装复制任务而不是扩展它可能会更好，并将方法添加到扩展类型以将闭包转发到复制任务。这有意义吗？是不是更“gradle-y”？

【解决方案2】：

您可以做的一件事是在您的扩展程序上调用一个方法并提供“配置”作为闭包。所以不是

// build.gradle

myExtension {
    // configure cool stuff
}

你写

// build.gradle

myExtension.config {
    // configure cool stuff
}

扩展类中的相应方法如下所示：

// MyExtension.groovy

class MyExtension {
    Project project

    MyExtension(Project project) {
        this.project = project
    }

    def config(Closure cl) {
        // Do stuff with the closure
    }
}

但是，当整个闭包被转发到您自己的代码时，您将丢失 Gradle 通常对配置闭包所做的所有评估。

【讨论】：