repository·main·Indexed 43 days ago
https://github.com/jetbrains/kotlin-toolchainA unified entry point for Kotlin development providing a declarative way to build applications across JVM, Android, iOS, multiplatform, and server-side platforms. It includes a CLI for build and execution tasks, integration with IntelliJ IDEA via the Kotlin Toolchain plugin, and the Amper CLI for project management and Maven-to-Amper conversion.
compose-resources library provides logic for generating code related to Compose resources. While it is currently part of the Amper project, it is designed to be fully independent of Amper and contains no dependencies on Amper modules. The implementation is largely derived from the compose-multiplatform Gradle Plugin's resource handling logic.The Kotlin Toolchain supports several product types for building native applications that run directly on the host operating system. The available types are:
linux/app: A native Linux application.macos/app: A native macOS application.windows/app: A native Windows application.If you are using IntelliJ IDEA, it is recommended to install the Kotlin Multiplatform plugin to ensure proper support for Kotlin/Native development.
The Maven converter is a tool designed to migrate projects from Maven to Amper. It processes the Maven model by building a plexus container and follows these conversion rules:
packaging = pom are treated as aggregators. They are used to populate the project.yaml file with Amper submodules.packaging = jar are converted into actual Amper modules (module.yaml).The conversion process involves multiple passes where the Maven model is traversed to build an Amper forest using a merging and refining process based on the TreeNode data structure.
The Kotlin Toolchain manages task execution based on @Input and @Output annotations:
@Input paths have not changed relative to their previous @Output paths, the task is skipped.@Input path that matches an @Output path from Task A, the toolchain automatically infers that Task B depends on Task A.@Output will always run because they are typically used for diagnostics or deployment and do not contribute to the build graph's state.The Kotlin Toolchain uses execution avoidance to skip tasks that don't need to run. By default, a task is considered up-to-date if:
@Input and @Output file trees (based on file attributes and modification time) is unchanged.Note: File content is not currently checked; only attributes and modification times are used.
Control this behavior using the executionAvoidance parameter in the @TaskAction annotation:
ExecutionAvoidance.Automatic (default): Computes up-to-dateness. If no outputs are declared, the task always re-runs.ExecutionAvoidance.Disabled: The task always re-runs. Use this for tasks with complex side effects or manual up-to-date logic.@TaskAction(executionAvoidance = ExecutionAvoidance.Disabled)
fun alwaysRunTask(input: @Input Path) {
// ...
}To manage multiple modules, create a project.yaml file at the project root. This file defines the project structure by listing the paths to all modules under the modules key.
Example structure:
project.yaml (root)jvm-app/module.yaml (application module)shared/module.yaml (library module)# project.yaml
modules:
- ./jvm-app
- ./sharedWhen converting Maven projects, plugin support is split into two categories:
amper-maven-plugins-compatibility).Handling Unsupported Configurations: If a plugin configuration cannot be fully supported (for example, if a goal is configured across several different executions), the converter will notify the user via YAML comments in the generated files. These comments are mapped to the corresponding YAML keys during the rendering phase to ensure users are explicitly informed of potential issues.
The Kotlin wrapper script acts as the source of truth for the toolchain version.
If you use a globally installed Kotlin CLI (e.g., via SDKMAN), it will not blindly use its own version. Instead, it searches the current directory and its parent directories for a project containing a project.yaml or module.yaml file and a kotlin wrapper script. If found, the global CLI will use the Kotlin Toolchain version and distribution checksum specified by that wrapper, ensuring the project is built with its declared version.
It is possible to have a module located at the project root even in a multi-module project, though this is generally discouraged. If a root module exists, it is included implicitly in the project.yaml file, and you only need to list the other modules in the modules section.
# Root module layout
├─ lib/
│ ├─ src/
│ │ ╰─ util.kt
│ ╰─ module.yaml
├─ src/ # src of the root module
│ ├─ main.kt
│ ╰─ ...
├─ module.yaml # the module file of the root module
╰─ project.yaml# project.yaml
modules: # The root module is included implicitly
- lib