Cómo interpretar Gradle DSL

Question

Estoy tratando de aprender Gradle. Mi estilo preferido de aprendizaje es comprender a un nivel bajo lo que está sucediendo. A tal fin, que estoy tratando de interpretar lo que está sucediendo en example 6.1 de la documentación con respecto a la DSL reference:

task hello { 
    doLast { 
     println 'Hello world!' 
    } 
} 

entiendo que este script se ejecuta en el contexto de un Project. Entonces puedo ver por el Projectdocumentation que hay una cantidad de métodos task(...) sobrecargados. Al mirar las firmas, necesito elegir una que tenga un cierre como argumento final. Y dado que no estamos pasando un Map aquí, supongo que el método que se está llamando es task(String name, Closure closure).

Sin embargo, la parte con la que estoy luchando es cómo, en este script, la cadena literal hello se correlaciona con un String.

Otro ejemplo es example 6.7:

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

task taskY << { 
    println 'taskY' 
} 

Aquí, supongo que estamos llamando a la forma del método task(Map<String, ?> args, String name). Pero,

1. Una vez más, ¿cómo la cadena literal taskX terminar como un String?
2. Dado que los paréntesis no se usan para construir un literal Map, ¿cómo la parte entre paréntesis termina siendo un Map?
3. Si he averiguado correctamente qué método se está llamando, ¿no son los argumentos dados en el orden incorrecto en la secuencia de comandos en comparación con la documentación de DSL?
4. La sintaxis que usa paréntesis se ve por todo el mundo como una llamada a método. Lo que podría indicar delegación en el objeto Project para resolver taskX como un método desconocido. Pero, AFAIK, una llamada a un método no sería sintácticamente válida en este punto dado el método llamado a task que lo precede inmediatamente.

Como puede ver, estoy un poco confundido sobre cómo la sintaxis de ejemplo se relaciona con la guía de referencia DSL, lo que me dificulta entender realmente lo que está sucediendo a nivel de base .

Gracias!

Answer 1

La variación task foo de la sintaxis de declaración de tareas es especial ya que se implementa utilizando un complemento de compilador Groovy. Hasta donde yo sé, este es el único caso donde se usa un complemento de compilación para soportar una sintaxis especial.