检索自定义插件中的conventionMapping [英] Retrieving conventionMapping in custom plugin

问题描述

我正在编写一个使用我的自定义扩展对象的gradle自定义插件。我明白，我必须使用conventionMapping懒惰地评估从这个SO答案和 gradle论坛。

我正在尝试使用普通的Gradle API（不是 DSL API ）编写我的插件。我认为我想这样做是因为它对IDE更友好。所以创建任务就像这样完成：

  MyTask task = project.tasks.create（mytask，MyTask）
 task.?conventionMapping？ .. 
  

而不是

  project.task（type：MyTask）{
 conventionMapping.field = .. 
} 
  

MyTask正在扩展DefaultTask，所以它没有conventionMapping字段。然后我发现Gradle的Java插件中的一些Task实现扩展了ConventionTask，我认为我应该扩展它，但不幸的是，这些事实让我感到困惑：

1. ConventionTask包是内部的


2. DefaultTask用@NoConventionMapping注解

我还发现这个帖子说我不应该约定。
因此，我的问题是conventionMapping仍然是编写使用扩展插件的正确方法？如果是的话，在没有gradle dsl magic的情况下检索它们的正确方法是什么？解析方案

当前最强大的解决方案是公约映射可用于解决延迟配置问题，但它被认为是内部功能。在某些时候，它将会消失，转而采用新的配置模式（这将是一项公开功能）。同时，解决延迟配置问题的另一个解决方案是使用诸如 project.afterEvaluate {...} 之类的回调。

I'm writing a gradle custom plugin which uses my custom extension object. I got to understand that I have to use conventionMapping to lazily evaluate the extension object value from this SO answer and gradle forum.

The problem happens when I'm trying to write my plugin with the normal Gradle API (not the DSL API). I figured that I wanted to do this because it is more IDE friendly. So the task creation is done like so:

MyTask task = project.tasks.create("mytask", MyTask)
task.?conventionMapping? ..

instead of

project.task(type:MyTask) {
   conventionMapping.field = ..
}

MyTask is extending DefaultTask, so it doesn't have conventionMapping field. Then I found out that some of the Task implementation from Gradle's Java plugin is extending ConventionTask, which I thought I should extend from, but unfortunately these facts make me confused again:

1. ConventionTask package is internal
2. DefaultTask is annotated with @NoConventionMapping

I also found this thread saying that I should not conventions. So my question, is conventionMapping still the correct way to write a plugin which uses extension? If yes, what's the correct way of retrieving them without the gradle dsl magic?

解决方案

Convention mapping is the most powerful solution that's currently available to solve the "deferred configuration" problem, but it is considered an internal feature. At some point, it will go away in favor of the new configuration model (which will be a public feature). Meanwhile, another solution to solve the "deferred configuration" problem is to use callbacks such as project.afterEvaluate { ... }.

这篇关于检索自定义插件中的conventionMapping的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！