I attended the talk on Gradle by Hans Doktor tonight and while I found myself agreeing that Maven is wholly unsatisfactory I did end up thinking that actually our expectations of build tools in the Java space are really low. What kind of things does Gradle offer us? Proper event interception, genuine integration with the build lifecycle, build targets dynamically defined at runtime, a directed cyclic dependency graph.
Looking at the list some of things you can’t believe are not part of our standard build package. We should be able to know when a build starts and stops and be able to attach code to those events. We should have decent target resolution that avoids duplication of tasks.
Gradle is head and shoulders about the morass that is Maven and is clearly superior to the ageing but faithful Ant but that it manages to be so on so little functionality is a shame.
Echo One 
The talk couldn’t cover all aspects of Gradle. Of course Gradle has also a focus on functionality (OSGi, web app debugging, reporting, …). If this is what you mean with functionality?
It is almost literally what we talked about in the pub that the functionality is, in ways, only trying to achieve parity with things like Rake and Make. There’s really not much ground being broken in Java build tools.
Another example I thought of after posting was that there’s a real lack of inference or intelligence in build tools. For example if I am packing some Java code into a Jar and just one of my classes has a main method. Why not make that the Main Class Attribute of the Jar manifest?
Where is the in-built support for rezipping jars into one delivery jar?
In many ways the Java build tool world is so impoverished that we look for any improvement with relief.
Gradle is not just about trying to achieve parity with Rake. Which is by the way not very hard. What we are trying to provide is a rich domain for building Java projects. We have come a long way already but this is an ongoing process. Only with such a rich domain model you can provide the intelligence you are asking for without paying with rigidity. One example for this (this is from a thread of our mailing list) is in regard your example from above:
It would be easy to provide such a fatJar task for the default jar task. This would be the framework way of doing things (like Maven does).
But it would be much cooler, if there were the pattern fat which works for any jar that is related to source directories. To make this possible we need a richer abstraction for source directories which we plan to do for 0.8. If we have such source dir objects you could also define a jar like:
task mySrcJar {
add srcDir // srcDir is not String but a rich object, which knows all of the srcDir including its classpath
fat = true
}