Learn Kotlin - Build Tools & Project Configuration

#Introduction

A healthy Kotlin project isn't determined only by its code, but also by its build configuration. Episode 14 masters the Gradle Kotlin DSL: writing build scripts in Kotlin itself, managing dependencies, structuring multi-module projects, and publishing artifacts.

Gradle is the dominant build tool in the Kotlin ecosystem. With the Kotlin DSL, build files become type-safe: configuration errors are caught at compile time rather than at runtime. This brings the Kotlin paradigm to the build layer itself.

After this episode, you'll build a tidy multi-module project and understand how Gradle works behind the scenes.

#Gradle Kotlin DSL and Build Scripts

#The Main Build File

A Gradle Kotlin project consists of settings.gradle.kts for project configuration and build.gradle.kts for each module. An example of a simple module file:

build.gradle.kts

plugins {
    kotlin("jvm") version "2.0.0"
    application
}
 
repositories {
    mavenCentral()
}
 
dependencies {
    implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:1.9.0")
    testImplementation(kotlin("test"))
}
 
application {
    mainClass.set("id.devnull.MainKt")
}

kotlin("jvm") uses the official Kotlin plugin, repositories tells Gradle where to look for dependencies, and application configures the main class for ./gradlew run. The entire file is Kotlin code — complete with type checking and IDE autocomplete.

#Gradle Wrapper

Always use the Gradle Wrapper so the Gradle version is locked per project. The gradle/wrapper/gradle-wrapper.properties file determines the version, and ./gradlew runs that version without needing a global Gradle install:

./gradlew build
./gradlew --version

./gradlew build compiles, runs tests, and packages the application. The wrapper guarantees every team member uses the same Gradle version, eliminating "works on my machine" problems.

#Dependency Management

#Dependency Configuration and Version Catalog

Dependencies are declared in the dependencies block with configurations like implementation, testImplementation, and api. For large projects, a version catalog (libs.versions.toml) centralizes dependency versions in one place:

[versions]
kotlin = "2.0.0"
coroutines = "1.9.0"
 
[libraries]
kotlinx-coroutines-core = { module = "org.jetbrains.kotlinx:kotlinx-coroutines-core", version.ref = "coroutines" }

The TOML block above defines centralized versions and libraries. In build.gradle.kts, using them becomes implementation(libs.kotlinx.coroutines.core). Version catalogs simplify upgrades and keep versions consistent across modules.

#Which Configuration for What

A quick guide to configurations:

• implementation: the dependency is used by this module, not exposed to consumers.
• api: the dependency is exposed in the module's public API.
• testImplementation: the dependency is only for tests.
• compileOnly: the dependency is available at compile time and provided at runtime.

Choosing the right configuration prevents dependency leakage and speeds up builds.

#Multi-module Projects

#Structuring Modules with Clear Purpose

Large projects are split into modules so architectural boundaries are visible and compilation can be parallelized. A common structure: :core:model for data, :core:domain for business logic, and :app for the application. The setup in settings.gradle.kts:

settings.gradle.kts

rootProject.name = "belajar-kotlin"
 
include(":core:model")
include(":core:domain")
include(":app")

include registers each module. Gradle analyzes the dependencies between modules to optimize builds incrementally and parallelize independent modules.

#Build Performance

Some practices keep builds fast:

• Use the build cache: ./gradlew build --build-cache.
• Avoid declaring excessive dependencies in the root project.
• Keep configuration stable so it doesn't change between tasks.
• Use consistent JDK and Gradle versions.

A consistent wrapper plus an active cache make builds fast and deterministic both in CI and locally.

#Publishing Artifacts and Versioning

#Publishing to a Repository

Libraries you want to share are published as artifacts. The maven-publish plugin configures publishing:

Publishing

plugins {
    `maven-publish`
}
 
publishing {
    publications {
        create<MavenPublication>("maven") {
            from(components["java"])
        }
    }
    repositories {
        maven {
            url = uri("https://my.repo.dev")
        }
    }
}

The publishing block defines the artifact and the target repository. The command ./gradlew publish uploads the artifact to the repository, so other modules or teams can use it as a dependency.

#Disciplined Versioning

Correct versioning uses Semantic Versioning: MAJOR.MINOR.PATCH. Bump MAJOR for breaking changes, MINOR for new features, and PATCH for bug fixes. Gradle reads the version from the version property, and CI can automate version bumps based on commit type — a pattern you'll see in episode 19.

#Closing

Episode 14 mastered build tools and configuration: the type-safe Gradle Kotlin DSL, version catalogs for centralized dependencies, multi-module projects with build performance, and publishing artifacts with semantic versioning.

The key takeaways:

• build.gradle.kts and settings.gradle.kts are the center of project configuration.
• The Gradle Wrapper locks the Gradle version per project.
• A version catalog centralizes dependency versions in libs.versions.toml.
• Multi-module splits architectural boundaries and speeds up builds.
• Build cache and clean configuration keep build performance high.
• Publishing uses the maven-publish plugin; versioning uses semantic rules.

In episode 15 we'll discuss performance optimization — JVM tuning for Kotlin applications, inline functions and reified types, memory management with allocation minimization, and profiling tools and optimization patterns that truly make an impact.