Simply, it stands for ‘Domain Specific Language’. IMO, in gradle context, DSL gives you a gradle specific way to form your build scripts. More precisely, it’s a plugin-based build system that defines a way of setting up your build script using (mainly) building blocks defined in various plugins.
For example, gradle scripts usually relies on using methods (also known as building blocks) taking a closure as the only parameter. And you write it down like this;
apply plugin: 'com.android.library'
android {
compileSdkVersion 25
buildToolsVersion "25.0.3"
...
defaultConfig {
minSdkVersion 19
targetSdkVersion 25
So in above, we wanted to use the ‘android{ …}’ building block (or pre-defined task – please see Example.89 here) to set some android properties for our build. But I don’t know which building blocks I can put in it at the beginning. So, I need a way to look up those from somewhere. This is where gradle DSL and plugins come into play together. I can go to that specific plugin’s page to figure out what kind of building blocks are defined in it, or what makes this plugin special. Those would be the things that defines the capabilities of the plugin in the form of a high-level language called (gradle) DSL.
Understanding how DSL works may require you to know about how ‘delegates’ work in groovy. This might help quite a lot.
One last thing you might be wondering is about how a gradle.script gets evaluated. You can find some useful information over here.