Three Gradle Talks from KotlinConf 2026 (and What to Steal from Each)
Table of Contents
Introduction
Every year I tell myself I’ll watch every conference talk I missed. Every year I get through maybe three before a build breaks and I get pulled back into real life.
KotlinConf is the one event where I actually follow through, partly because the talks are short and dense, and partly because a good chunk of my coworkers and friends are on stage. This year in Munich, three of them talked about Gradle: Paul Merlin on the history of our DSLs, Stefan Wolf on best practices, and Marcin Mycek on Declarative Gradle for Kotlin.
I watched all three so you can decide which ones are worth your fifteen minutes.
A Tale of the Gradle DSLs — Paul Merlin #
Paul has been inside Gradle’s DSL machinery for years, which makes him exactly the right person to tell this story and exactly the wrong person to pretend the early days were clean.
The talk traces how build logic went from Groovy, to the Kotlin DSL, to Declarative Gradle. The useful part isn’t the timeline. It’s that each of those was solving a real problem the previous one couldn’t.
Groovy gave us a flexible, dynamic scripting language, which was great right up until you wanted your IDE to tell you what was valid. The Kotlin DSL brought static typing, real autocompletion, and refactoring that doesn’t rely on hope. That’s why the Kotlin DSL is now the default for new Gradle builds. Declarative Gradle is the next swing: describe what your build is rather than script how it runs.
The honest through-line is that none of these fully replaces the last one. Kotlin DSL is where most people should be today. Groovy still runs an enormous amount of the world’s build logic and isn’t going anywhere fast. Declarative Gradle is early but points at where things are headed.
Real talk: if your build scripts are still Groovy and still working, you don’t have to panic-migrate this weekend. But if you’re starting something new, reach for the Kotlin DSL and let the IDE carry some of the weight.
10 Gradle Best Practices Every Kotlin Developer Should Know — Stefan Wolf #
Stefan has been on the Build Tool team for a decade and now works on Develocity, so when he lists ten things, it’s ten things he’s watched break in real builds.
The talk splits neatly into two buckets: how you organize a build, and how you optimize it. Most of these are cheap to adopt and quietly pay for themselves. The full write-up lives in the Kotlin docs, but here’s the shape of it.
On the organizing side:
- Use the Kotlin DSL. Same argument as Paul’s talk, type safety and IDE support you don’t have to earn.
- Use a version catalog. Put your versions in a
libs.versions.tomland stop chasing the same dependency string through fifteen build files. - Use convention plugins. Move shared build logic into a plugin once so every module isn’t a copy-paste of the last one. Setup takes an afternoon; maintenance takes minutes.
On the optimizing side:
- Turn on the local build cache. Reuse outputs you’ve already produced instead of rebuilding them.
- Turn on the configuration cache. Cache the configuration phase and skip it when nothing relevant changed. It also nudges you toward parallel execution.
- Speed up multi-target builds. When you’re iterating on one platform, run the specific
linkDebug*task instead of compiling every target throughbuild. - Migrate from kapt to KSP. KSP reads your source directly instead of generating Java stubs, so annotation processing gets meaningfully faster.
- Modularize (if you’re big enough). Splitting a moderate-to-large project into subprojects means a change in one place rebuilds one place. Skip this for tiny projects; it’s overhead you won’t recoup.
- Set up CI/CD with caching. Persist dependencies and task outputs between runs so your pipeline isn’t starting from zero every time.
- Use a remote build cache. Share task outputs across the whole team and CI, so a fresh checkout can pull results someone else already computed.
The theme underneath all ten: stop paying for work you’ve already done. Most Gradle “slowness” is just a build redoing things it didn’t need to.
Pro tip: if you only do two of these this quarter, turn on the configuration cache and adopt a version catalog. Biggest return for the least ceremony.
A First Look at the Kotlin Ecosystem Plugin for Declarative Gradle — Marcin Mycek #
This one’s a lightning talk, so it’s a quick look rather than a deep dish, and that’s the right format for where the project is.
Marcin demos the Kotlin ecosystem plugin for Declarative Gradle, which is our attempt at a genuine reset on how builds get authored. Instead of a build script that runs top to bottom, you declare the shape of your project in .dcl files, and the plugin knows what a Kotlin JVM application or library is supposed to look like.
The idea is high-level building blocks that read the same across ecosystems. A kotlinJvmApplication block does for Kotlin what the equivalent does for Java or Android, so the concepts transfer instead of resetting every time you switch stacks. That consistency is also what should make it easier to add new ecosystems later.
The part I appreciated: you don’t have to convert everything at once. Declarative Gradle supports mixed builds, so .dcl files can sit alongside existing Groovy or Kotlin DSL scripts while you try it on one module.
Fair warning, and Marcin is upfront about this: the plugin is experimental and moving quickly. Things will change under you. That’s the deal with an early look, you get to see where it’s going and shape it, in exchange for a little instability.