|
Since I mentioned Gradle aggravations, I'll share a couple: 1. Bizarre and inscrutable syntax. They say things like "build scripts are just Groovy code", but some things, like how you define sourcesets or configurations, don't look like anything that should parse, much less compile, in any C-like language. They're doing some fancy meta-programming stuff behind the scenes to keep things light and simple, but it really isolates (and possibly alienates) developers from exactly what's happening under the covers. The Kotlin DSL seems to help make it more clear what's going on, but I haven't used it much yet. Having used Gradle for years, it is strangely off-putting how unsure I often am about whether to put a colon in a particular place or a comma, or if something should be in parenthesis. 2. If you want to do anything beyond what's documented you can get into a bit of trouble, and if you find answers more than a couple of years old there's a good chance they often won't work. Making sense of the DSL documentation is sometimes a little tricky. Beyond that, I would dare say it's the least awful option for building for the JVM. Their documentation is very comprehensive, it's fast, they are very fair about providing deprecation warnings before features are removed. It's rare I find a case where I'd like to use some external library that has a Maven plugin but no Gradle support. |
The first parameter in a Groovy closure it will be treated as "this" and any function you call can applied to "this" first.
sourceSets is just a function that accepts a closure whose first parameter is sourceSets (this is implementation specific). If you call main inside the closure then groovy will call sourceSets.main and set that property.
What you are probably complaining about is that parenthesis are optional in two contexts. Your function fits on a single line or your last parameter is a closure (curly braces)
You're also confused by the fact that you can pass a map as a parameter by simply doing "function key1: name1, key2: name2".