Retrieving conventionMapping in custom plugin

问题:

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?

回答1:

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 { ... }.