如何解读Gradle DSL

dty*_*dty 31 gradle

我正在努力学习Gradle.我偏好的学习方式是从低层次了解正在发生的事情.为此,我试图解释有关DSL参考的文档的示例6.1中发生的情况:

task hello {
    doLast {
        println 'Hello world!'
    }
}
Run Code Online (Sandbox Code Playgroud)

我知道这个脚本是在一个上下文中执行的Project.所以我可以从Project 文档中看到有很多重载task(...)方法.看一下签名,我需要选择一个有闭包作为最终参数的签名.因为我们没有在Map这里传递,所以我假设被调用的方法是task(String name, Closure closure).

但是,我正在努力的部分是,在这个脚本中,文字字符串如何hello映射到a String.

另一个例子是例6.7:

task taskX(dependsOn: 'taskY') << {
    println 'taskX'
}

task taskY << {
    println 'taskY'
}
Run Code Online (Sandbox Code Playgroud)

在这里,我假设我们正在调用task(Map<String, ?> args, String name)方法的形式.但,

  1. 再一次,文字字符串如何taskX最终成为String
  2. 鉴于括号不用于构造Map文字,括号中的部分如何最终成为Map
  3. 如果我已经正确地找出了调用哪个方法,那么与DSL文档相比,脚本中错误顺序的参数是不是?
  4. 使用括号的语法像方法调用一样查找全世界.这可能表示委托给Project对象解析taskX为未知方法.但是,AFAIK,方法调用在这一点上在语法上不会有效,因为方法调用task紧接在它之前.

正如您所看到的,我对示例语法如何映射到DSL参考指南感到有点困惑,这让我真的很难理解基层正在发生的事情.

谢谢!

Pet*_*ser 19

task foo任务声明语法的变化是特殊的,因为它是使用Groovy编译器插件实现的.据我所知,这是唯一一个使用编译器插件来支持特殊语法的情况.

  • 有趣.我对Groovy比较陌生,其中一件我不喜欢的事情是,当人们完成这样的"聪明"事情时,弄清楚发生了什么事情是多么困难 - 通常是为了让他们的DSL易于使用/写入.关于如何在脚本和DSL参考指南之间进行翻译(在我的脑海中),您有什么具体的建议吗? (6认同)
  • `的gradle /子项目/核心/ SRC /主/常规/组织/ gradle这个/常规/脚本/内部/ TaskDefinitionScriptTransformer.java` (5认同)