This is in fact a very important difference. One is a closure that is run against the API of the task object and configures it. The other is a closure that get's executed after the configuration phase. If you do something like:

task c << { print 'c' }
task a(dependsOn: c) << { print 'a' }
task b(dependsOn: c) { print 'b' }

If you do gradle b, the output will be: bc. If you do gradle a, the output will be: ca. There is a simple reason for this. The closure of b is a configuration closure which is supposed to configure the b object. This is done before any task is executed. In fact, even if you execute gradle -t, b will be printed, as this part of the evaluation of the build script. A gradle -t will only trigger the configuration phase of the build script. So setting the description in an action won't have any effect on the output (as those actions are not executed). There is also another important difference between a configuration closure and an action closure. A configuration closure has the task object as a delegate. The action closure not! So if you really want to set the description property or any other task property in an action, you would need to do:

task a << { task ->
   task.someProperty = 'value'
}

But as described above. This wouldn't be picked up by gradle -t

Hi Hans,

I raised the same issue some time ago (http://jira.codehaus.org/browse/GRADLE-513) so let me comment on this. I understand there are important reasons why Gradle behaves the way it does, but from the user point of view, the situation looks as following:
a) a task can have a description which is printed when executing gradle -t
b) I create a task with << and I'd like to add description to it
c) ups, it doesn't work ! it is surely a bug ! I will rise JIRA issue for this

My point is, that the user is right. What he expects is reasonable and Gradle should be able to do it.
If it is not possible using "description=whatever" statement, than it should be very clearly stated in the documentation how can the description be added to the task created by << (BTW. the code you provided in this ticket is not readable - something went wrong with formatting).

–
best regards
Tomek Kaczanowski
http://kaczanowscy.pl/tomek

Reopen to edit a broken formatting in a comment

I agree. The user's guide should be clear about this. Anyway, I forgot to add how to do it the right way.

task a(description: 'I print a') << {
println 'hello'
}

task(b) {
description = "I print b"
}.doLast

Unknown macro: { println 'b' }

The first example is usually the way to go. The second example is just for demonstrating the logic explained above a bit better.