# Gradle's leaky abstractions: Declarative(ish) shell, imperative core: Implementing a safe(ish) global configuration DSL

DevFeed: [Gradle's leaky abstractions: Declarative(ish) shell, imperative core: Implementing a safe(ish) global configuration DSL](<https://devfeed.tech/articles/gradle-s-leaky-abstractions-declarative-ish-shell-imperative-core-implementing-a-safe-ish-global-configuration-dsl-30462.md>)

Original publisher: [Read original article](<https://dev.to/autonomousapps/gradles-leaky-abstractions-declarativeish-shell-imperative-core-implementing-a-safeish-global-configuration-dsl-5e63>)

Author: Tony Robalik

Published: 2024-03-23T19:20:30Z

Content type: tutorial

Language: en

Sources: [DEV Community: Tony Robalik](<https://devfeed.tech/sources/dev-community-tony-robalik.md>)

Topics: [Gradle](<https://devfeed.tech/topics/gradle.md>), [configuration](<https://devfeed.tech/topics/configuration.md>), [Script](<https://devfeed.tech/topics/script.md>), [Code](<https://devfeed.tech/topics/code.md>)

Tags: [build](<https://devfeed.tech/tags/build.md>), [coding](<https://devfeed.tech/tags/coding.md>), [community](<https://devfeed.tech/tags/community.md>), [configuration](<https://devfeed.tech/tags/configuration.md>), [dependencies](<https://devfeed.tech/tags/dependencies.md>), [development](<https://devfeed.tech/tags/development.md>), [engineering](<https://devfeed.tech/tags/engineering.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [inclusive](<https://devfeed.tech/tags/inclusive.md>), [java](<https://devfeed.tech/tags/java.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [programming](<https://devfeed.tech/tags/programming.md>), [software](<https://devfeed.tech/tags/software.md>)

## AI overview

This article explains how Gradle build scripts combine a declarative-looking DSL with imperative programming, including how special blocks can be evaluated out of top-down order. It then outlines a safer global configuration design using a shared build service so subprojects can query configuration data without directly accessing one another's mutable state.

## Source excerpt

Gradle is very aware they have a complexity problem. Fundamentally, the problem is that Gradle build scripts use an Actual Programming Language (either Groovy or Kotlin), and therefore provide users access to the complete Java/Groovy/Kotlin ecosystem--the JDK, the standard libraries, and all the other libraries too. Gradle wants you to write your scripts like this: // build.gradle.kts // so declarative! plugins { id("foo") } dependencies { implementation(libs.coolThing) } myExtension { ... } but what that boils down to is just this: // er, imperative? project.pluginManager.apply("foo") project.dependencies.add("implementation", libs.coolThing) project.extensions.getByType(MyExtension::class.java).run { ... } which in turn is this: // yeah, definitely imperative FooPlugin().apply(project) { ... all the code in FooPlugin.apply() ... } ... etc ... Where one of the most important takeaways here is that build scripts are evaluated top-down, one "declarative block" after the other. Although, even that is not necessarily true. Kotlin DSL confuses this. Here's a valid settings script: // settings.gradle.kts rootProject.name = "..." pluginManagement { ... } buildscript { ... } dependencyResolutionManagement { ... } plugins { ... } Gradle will not complain if you do this, but actually some of these blocks are Special and get evaluated not in top-down order. buildscript is the Primordial Special block; it is always evaluated first (which makes sense, as it contributes dependencies to the script itself). pluginManagement is evaluated next, followed by plugins, followed by everything else. Sometimes, when I'm working on a build, I will reorder blocks to match actual evaluation order because I want users to remember this (implicitly), but mostly I've given up. Note that, in a Groovy DSL script, Gradle will actually complain and refuse to compile a script that is written out-of-order. ¯\_(ツ)_/¯ What about afterEvaluate and various other lazy callbacks? This isn't a master's thesis.