How to interpret Gradle DSL

Question

I'm trying to learn Gradle. My preferred style of learning is to understand at a low level what is going on. To that end, I am trying to interpret what's happening in example 6.1 of the documentation with respect to the DSL reference:

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

I understand that this script is executed in the context of a Project. So I can see from the Project documentation that there are a number of overloaded task(...) methods. Looking at the signatures, I need to chose one which has a closure as the final argument. And since we're not passing a Map here, I assume the method that's being called is task(String name, Closure closure).

However, the part I'm struggling with is how, in this script, the literal string hello gets mapped to a String.

Another example is example 6.7:

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

Here, I assume we're calling the task(Map<String, ?> args, String name) form of the method. But,

1. Again, how does the literal string taskX end up as a String?
2. Given that parentheses are not used to construct a Map literal, how does the part in parentheses end up being a Map?
3. If I've correctly figured out which method is being called, aren't the arguments given in the wrong order in the script compared to the DSL documentation?
4. The syntax using parentheses looks for all the world like a method call. Which might indicate delegation to the Project object to resolve taskX as an unknown method. But, AFAIK, a method call wouldn't be syntactically valid at this point given the method call to task immediately preceding it.

As you can see I'm a bit confused as to how the example syntax maps down to the DSL reference guide, which is making it a bit tricky for me to really understand what's happening at a grass-roots level.

Thanks!

Answer 1

The task foo variation of the task declaration syntax is special in that it's implemented using a Groovy compiler plugin. As far as I know, this is the only case where a compiler plugin is used to support a special syntax.