Build and Tooling

This section documents Kotlin 2.4.x on the JVM, as published at kotlinlang.org, which is the reference these pages are written and verified against.

This content was generated with the assistance of AI and should be verified against kotlinlang.org before being relied on in production.

This section’s bibliography lists the reference material consulted while preparing these pages.

Most real projects never invoke kotlinc directly (see Getting Started) — Gradle or Maven drive the compiler as part of an ordinary build.

The Gradle Kotlin DSL (build.gradle.kts)

Gradle build scripts can be written in Kotlin itself (.kts, a .gradle.kts file extension) instead of the older Groovy DSL — this is the default for new Kotlin and new Android projects today, and gets full IDE autocompletion/type-checking, unlike a dynamically-typed Groovy script:

// build.gradle.kts
plugins {
    kotlin("jvm") version "2.4.0"
}

repositories {
    mavenCentral()
}

dependencies {
    implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:1.9.0")
    testImplementation(kotlin("test"))
}

tasks.test {
    useJUnitPlatform()
}

plugins { }, dependencies { }, and tasks.test { } are all lambda-with-receiver blocks over Gradle’s own configuration model — see Type-Safe Builders and DSLs for the language mechanism this is built on. An Android module additionally applies id("com.android.application") (or .library) alongside kotlin("android").

Maven’s Kotlin Plugin

Maven support comes from the kotlin-maven-plugin, bound to the compile/test-compile phases:

<build>
  <plugins>
    <plugin>
      <groupId>org.jetbrains.kotlin</groupId>
      <artifactId>kotlin-maven-plugin</artifactId>
      <version>2.4.0</version>
      <executions>
        <execution>
          <id>compile</id>
          <goals><goal>compile</goal></goals>
        </execution>
        <execution>
          <id>test-compile</id>
          <goals><goal>test-compile</goal></goals>
        </execution>
      </executions>
    </plugin>
  </plugins>
</build>

A mixed Java/Kotlin Maven module needs the Kotlin execution bound before maven-compiler-plugin’s own `compile phase so Java sources can reference Kotlin classes (see Kotlin and the JVM on interoperability) — both are described explicitly in the plugin’s own documentation.

IntelliJ IDEA and Android Studio

Both IDEs bundle first-class Kotlin support out of the box (Android Studio is itself built on the IntelliJ platform) — syntax highlighting, refactoring, a Java-to-Kotlin converter (paste Java code into a .kt file and IntelliJ offers to convert it automatically), and inline bytecode/decompiled-Java views of any Kotlin declaration, useful for understanding exactly what a given Kotlin construct compiles down to.

Static Analysis: ktlint and detekt

Two tools cover Kotlin’s equivalent of Checkstyle/PMD:

  • ktlint — a formatter/linter enforcing the official Kotlin coding conventions with no configuration needed for the common case; it can also auto-fix most violations.

  • detekt — a broader static-analysis tool (complexity, code smells, potential bugs) configured via a detekt.yml rule set, closer in spirit to PMD/SpotBugs than to a pure formatter.

// build.gradle.kts
plugins {
    id("org.jlleitschuh.gradle.ktlint") version "12.1.1"
    id("io.gitlab.arturbosch.detekt") version "1.23.7"
}

Both are typically run as their own Gradle tasks (ktlintCheck, detekt) alongside the ordinary test task in CI.

A Pointer to Kotlin Multiplatform

Kotlin and the JVM introduced Kotlin Multiplatform (KMP) as the mechanism for sharing Kotlin source across the JVM, JS, Native, and Wasm back ends. From a build-tooling perspective, KMP is configured via the kotlin("multiplatform") Gradle plugin instead of kotlin("jvm"), declaring one or more source sets (commonMain, androidMain, iosMain, …​) compiled to their respective targets from largely shared code — a large enough topic that it is only pointed at here, not covered in depth.

Publishing to Maven Central

A Kotlin/JVM library publishes through the exact same Sonatype Central Portal flow as a Java library: the same central-publishing-maven-plugin (Maven) or com.vanniktech.maven.publish (Gradle) plugins apply unmodified to a Kotlin source tree, since both work at the level of the packaged JAR and its signatures rather than the language that produced them.

See Publishing to Maven Central for the full account setup, user token, GPG key, and GitHub Actions release workflow — none of that is repeated here since nothing about it differs for Kotlin.

A Kotlin Multiplatform library publishes multiple platform-specific artifacts (JVM, JS, Native, …​) under one shared coordinate; com.vanniktech.maven.publish and the kotlin("multiplatform") plugin handle that automatically once each target is declared, with no extra publishing configuration beyond what a single-platform library needs.

See Also

References