Amper Merges into Kotlin Toolchain: What Does This Mean for Gradle’s Future?

Amper integrated into Kotlin Toolchain

Amper is now part of the Kotlin Toolchain and its name and amper command entry point are deprecated. The wrapper scripts amper / amper.bat are replaced by kotlin / kotlin.bat, and the IDE plugin switches from the Amper plugin to the Kotlin Toolchain plugin.

Unified CLI entry point

From version 0.11 the Kotlin Toolchain provides a single CLI for creating, building, running, testing and publishing projects. Typical commands are:

kotlin build

kotlin run

kotlin test

kotlin publish

The CLI automatically selects the appropriate wrapper version defined in the project, so projects are not forced to use a single toolchain version globally.

Motivation: fragmented Kotlin ecosystem

Kotlin compiler, Gradle, Kotlin Gradle Plugin, Android Gradle Plugin, Kotlin/Native, Xcode/iOS artifacts, Maven publishing, Maven Central signing, source sets and platform‑specific configurations are all separate pieces.

The Kotlin Toolchain consolidates these pieces into one official entry point, moving away from the legacy JVM‑centric build experience.

Publishing JVM libraries to Maven Central

Version 0.11 adds first‑class support for publishing JVM libraries to Maven Central. The toolchain automatically creates sources JAR, Javadoc JAR, performs PGP signing, generates POM metadata, computes checksums and builds the deployment bundle.

Publishing is declared in module.yaml and executed with: kotlin publish mavenCentral Example configuration:

product: jvm/lib

description: A meaningful description for this specific module

settings:
  publishing:
    enabled: true
    group: com.example   # must match Maven Central namespace
    version: 1.0.0
    mavenCentral: enabled
    signArtifacts: true   # automatic signing, no external GPG required
    publishSources: true
    pom:
      url: https://example.com
      scm: https://github.com/my-org/example.git
      developers:
        - name: John Doe
      licenses:
        - name: MIT
          url: https://opensource.org/license/mit

Publishing of Kotlin Multiplatform (KMP) libraries is not yet supported; only product: jvm/lib can be published.

Enhanced C‑interop support

The toolchain now generates C library bindings from .def files placed in the cinterop folder of a module. IDE synchronization also generates the bindings and provides assistance, reducing manual configuration in Kotlin/Native projects.

This unified C‑interop management cuts down extensive manual setup for KMP/Kotlin Native.

Terminal output and IDE synchronization improvements

Library sources are downloaded in the background after sync, allowing developers to start coding immediately.

IDE dependency resolution is aligned with CLI behavior at the module level, eliminating mismatched versions and warnings.

Consistency between CLI and IDE

The core value of the Kotlin Toolchain is the consistency between CLI and IDE, addressing long‑standing Gradle pain points such as:

Command line passes while IDE shows errors.

IDE shows no errors while CI fails.

Slow synchronization.

Inconsistent dependency resolution.

Complex source‑set / target / variant combinations.

New plugin development capabilities

checks

: plugins can register quality checks (e.g., lint) executable via kotlin check.

# my-lint-plugin/plugin.yaml

tasks:
  runLinter: !kotlinJavaLint
    sources: ${module.kotlinJavaSources}

checks:
  - name: lint
    performedBy: runLinter

commands

: plugins can expose public commands, for example kotlin do updateBaseline.

# my-lint-plugin/plugin.yaml

tasks:
  updateBaseline:
    action: !runDetektForBaseline
    sources: ${module.kotlinJavaSources}
    outputFile: ${module.rootDir}/detekt/baseline.xml

commands:
  - updateBaseline

generated

: unified declaration of generated sources, resources and C‑interop definitions, replacing the old markOutputAs mechanism.

tasks:
  generateStuff:
    action: !myGenerateStuffAction
    outputSources: ${taskOutputDir}/src
    outputResources: ${taskOutputDir}/res
    outputDefFiles: ${taskOutputDir}/cinterop

generated:
  sources:
    - directory: ${tasks.generateStuff.action.outputSources}
      language: kotlin
  resources:
    - directory: ${tasks.generateStuff.action.outputResources}
  cinteropDefinitions:
    - directory: ${tasks.generateStuff.action.outputDefFiles}

These generated artifacts are easier for humans, AI agents and other tools to recognize.

The article notes that YAML‑based declarative configuration is more approachable for AI coding agents than the executable Gradle Kotlin DSL, which contains conditionals, dynamic task registration and plugin magic that are hard to statically analyze.

Impact on Gradle visibility

With Amper now part of the Kotlin Toolchain, the kotlin entry point becomes the primary way to work with Kotlin projects. The traditional gradlew command will remain in the short term but its direct visibility is expected to diminish in new Kotlin‑first or KMP‑first projects.

Reference: https://blog.jetbrains.com/amper/2026/06/kotlin-toolchain-0-11/