

There is always at least the root project, which may contain subprojects, which in turn can have nested subprojects as well. Gradle build consists of one or more projects, and projects consist of tasks. init scripts used for global configuration (executed against Gradleinstance).settings scripts in adle files, executed against Settings object.

These are executed against Projectobjects ( closure, anyone?) executed against various objects: There are three main script files that Gradle uses. You can read more about delegation and delegation strategies in Groovy documentation. There’s actually a bit more to delegates and how closure’s statements are executed. We will see later why this is crucial in Gradle. We can see that printClosure calls printText method on the delegate it is provided (the same goes for properties). What’s different is that we can change the delegate of a closure. They’re blocks of code that can be executed, can have parameters, and return values. If you’re familiar with Kotlin, you might find below explanation somewhat similar to function literals with receiver.Ĭlosures in Groovy can be thought of as lambdas on steroids. One important feature that needs some explaining are closures. Mind that in both cases the result will be the same regardless of parameters order! Also notice omitted parentheses in both calls. This will print "John is 24 years old" followed by John works as Android developer at Tooploox. Other (non-named arguments) are then appended to parameters list:

Gradle files are basically Groovy scripts. In this post we’ll write, step by step, Gradle configuration files for a single Android project in order to take some of the magic away.

Anything more complicated than that, and we end up copy-pasting mysterious snippets from Stack Overflow, without understanding how they work. For most purposes we don’t need to modify our *.gradle files much we add dependencies, modify target and minimum API levels, maybe set up signing configs and build types.
