GradleKotlinConverter rewrites Groovy build scripts into Kotlin DSL

A converter you point at build files instead of a Gradle plugin

Migrating a Gradle build from the Groovy DSL to the Kotlin DSL is mostly typing work: quotes move, parentheses appear, block syntax changes, and the same reasoning has to be retyped for every module. GradleKotlinConverter takes that mechanical layer off your hands. It is described as a tool to convert from Groovy to Kotlin DSL for Gradle, focused on Android, and it works both in the browser at https://gradle-kotlin-converter.vercel.app/ and from a terminal.

What it is not is a Gradle plugin. Nothing is added to your build, no artifact is resolved into your classpath, and no task is registered. You hand it one script, it hands back rewritten Kotlin DSL text, and you decide what to do with it. That keeps the risk low for a first migration step, since a broken conversion shows up as a build failure you can inspect rather than as a plugin that quietly changes your build behaviour.

The target audience is a team sitting on a working Groovy build that has to move to Kotlin DSL, whether that is an Android application, a pure JVM project, or a Kotlin library. The web page is the primary interface and needs no setup at all. If your build scripts are small enough to paste, you paste them. If they are real project files, the local CLI reads them from disk.

Two implementations with different rule coverage

The repository holds two separate implementations, and this matters more than the feature list suggests. The top level entries are .github/, .gitignore, LICENSE, README.md, assets/, kotlin/ and web/, and the primary language is TypeScript.

The web/ directory is the complete implementation. It carries the full test suite and extra features, including the AGP migration warnings. The kotlin/ directory holds a single Kotlin script that covers the core conversions only. In the words of the project description, the Kotlin script covers the core conversions while web/ is the complete implementation with the full test suite and additional features.

So the local CLI and the browser interface are the same engine, while the standalone .kts script is a trimmed copy. Anyone evaluating the project should run the web or CLI path when judging coverage, because judging by the script alone will understate the number of transformations. The same distinction applies to bug reports: an issue about a missing transform is only meaningful against web/.

The practical upside of the script is that it needs nothing but a Kotlin compiler and the file itself. That makes it usable on a build machine where installing a Node toolchain is unwelcome, at the cost of the AGP warnings and the newer patterns.

The transformation table that drives the rewrite

The rewrite logic is a table of rules that map Groovy constructs to their Kotlin DSL equivalents, and reading the table tells you what the converter actually does. Strings gain double quotes, so `'kotlin-android'` becomes `"kotlin-android"`. A variable declaration with `def appcompat = "1.0.0"` becomes `val appcompat = "1.0.0"`. Plugin application moves from `apply plugin: "kotlin-kapt"` to `apply(plugin = "kotlin-kapt")`, and a dependency such as `implementation ":epoxy"` gains its parentheses.

Repository declarations are rewritten too: `maven { url "https://jitpack.io" }` becomes `maven("https://jitpack.io")`. Legacy SDK declarations are modernised in two directions, with `compileSdkVersion 28` becoming `compileSdk = 28` and `compileSdk 36` becoming `compileSdk = 36`. A version code turns into an assignment, so `versionCode 4` becomes `versionCode = 4`, and `debuggable true` becomes `isDebuggable = true`.

The harder rewrites are the block conversions. `sourceCompatibility = "1.8"` becomes `sourceCompatibility = JavaVersion.VERSION_1_8`, a `signingConfigs { debug { ... } }` block becomes `signingConfigs { register("debug") { ... } }`, and a `buildTypes { debug { ... } }` block becomes `buildTypes { named("debug") { ... } }`. Repeated `apply(plugin = ...)` calls are folded into a `plugins { id(...) ... }` block, and an `ext.kotlin_version = '2.1.20'` assignment becomes `extra["kotlin_version"] = "2.1.20"`.

Beyond the table, the converter handles version catalogs, `platform()` dependencies, `includeBuild`, `fileTree(mapOf(...))`, `artifacts { add(...) }`, `buildFeatures`, `testOptions` and Kotlin compiler options. It also works on `.kts` files, and the documentation claims that pasting a single dependency line such as `implementation '...'` still gets the parentheses and quotes added.

Running the converter against one build file locally

The documented local path goes through the web directory, which is where the CLI lives. Install the dependencies first, then point the CLI at a build file and redirect the output to a .kts file if you want to keep it:

cd web
pnpm install

pnpm cli build.gradle
pnpm cli build.gradle > build.gradle.kts

The first invocation prints the converted script to the terminal so you can read the diff before you commit to it. The second writes the result into build.gradle.kts next to it. Neither command touches your original file, so the Groovy script stays in place until the Kotlin version actually syncs.

If a Node toolchain is not available, the repository also ships a Kotlin script that runs on a Kotlin compiler:

kotlinc -script kotlin/gradlekotlinconverter.kts build.gradle
# or
./kotlin/gradlekotlinconverter.kts build.gradle

Expect less from that route. It covers the core conversions and skips the AGP migration warnings that the web implementation adds.

There is no published package name, no versioned release artifact and no install command for a global tool. The two routes above are the only entry points the documentation gives, so plan on cloning the repository rather than adding a dependency to your build.

TODO markers where the rewrite stops

The most useful thing this converter does when it fails is say so. The documentation is explicit that it is a best effort tool, compared to Android Studio's Java to Kotlin converter, and that it will not perfectly handle every case.

Some `ext { }` blocks that contain closures are only partly handled, and the tool inserts `// TODO` comments for manual review. Legacy or removed AGP and Gradle features that need a larger architectural change produce `// TODO(AGP)` notes. The AGP warning set covers items such as variantFilter, RenderScript and density splits, which are exactly the constructs that need a human decision rather than a syntax swap.

Some categories are simply out of reach. Complex custom Groovy logic, helper methods living in buildSrc, and heavy metaprogramming are not converted. Neither are the custom DSL extensions that individual third party plugins add. That is the wrong tool case: a project whose build logic is concentrated in buildSrc or in plugin specific DSL is a refactor, not a syntax migration, and running a regex style converter over it produces confident nonsense. A project that is mostly plugin blocks and standard dependencies is where this pays off.

The instruction that follows every conversion is the practical one: review the output, run a Gradle sync, and test your build.

Golden fixtures as the executable spec

The web/ implementation is guarded by two kinds of tests. The project mixes focused unit tests with full file golden fixtures stored in web/app/fixtures/golden/, and the rule set itself lives in web/app/logic.ts, which the documentation points to alongside the fixtures as the complete set of rules and realistic before and after examples.

Running the suite locally is a three line sequence:

cd web
pnpm install
pnpm test

This arrangement has a practical consequence for adopters. If the converter mishandles your build script, the fixtures show what the current behaviour is for that shape of input, which tells you whether you hit a known edge case or found a genuine gap. It also means the fixtures double as documentation, since they hold full scripts rather than isolated assertions.

For a team that wants to keep the converter in the loop, that layout is what makes it extensible in practice. A golden fixture for your own build layout can serve as a regression check, because a change in the rules that alters your case shows up as a fixture diff. The cost is that the tests are JavaScript and TypeScript tooling, so a Gradle only shop inherits a pnpm dependency it otherwise would not carry.

Licence, release history and what an upgrade costs

The licence field on the repository says Apache-2.0. That is a permissive licence with an explicit patent grant and a requirement to keep notices in redistributions, so embedding the converter in internal tooling carries no licence fee and no source disclosure obligation for your own build scripts. This is a statement about the licence terms themselves, not advice on how to apply them.

The release history has an unusual shape. Version 0.5 shipped on 2019-02-15 with the addition of compile to implementation, the colon to equals change, and improved documentation. Version 0.6 shipped on 2020-03-18 with many new conversions and the project's first test. Version 0.7 shipped on 2026-06-24 and is described as a 2026 update in which everything is new. That is a six year gap between 0.6 and 0.7, so the numbered releases do not tell you much about continuity.

The last push was on 2026-09-16, and the repository is not archived, so there is recent work behind the 0.7 tag. The upgrade cost depends on which route you took. The kotlin/ script is a single file you can read end to end. The web/ implementation is a TypeScript project that needs pnpm, and moving to it means picking up the current rule set rather than patching an old script. Since the transformation table is the product, check web/app/logic.ts against the rules your build depends on before you switch, and expect to re-review converted scripts that were produced by an older version.

Editorial conclusion

Adopt GradleKotlinConverter when you face a folder of legacy Groovy build files and only want the mechanical changes done for you, and skip it when your build logic lives in buildSrc helpers or third party plugin extensions, since those are left untouched. Before you trust the output, paste one of your real build.gradle files through it, check every // TODO and // TODO(AGP) note, and run a Gradle sync, because the converter states plainly that it is a best effort tool and expects a human review pass.

Frequently asked questions

Official sources

1. bernaferrari/GradleKotlinConverter on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases