Spec-Zone.ru › Kotlin 1.7

Gradle

Gradle — это система сборки, которая помогает автоматизировать и управлять процессом сборки. Она загружает указанные зависимости, упаковывает ваш код и подготавливает его к компиляции.

Для сборки проекта Kotlin с помощью Gradle вам нужно добавить плагин Kotlin Gradle и настроить зависимости.

Применение плагина

Для применения плагина Kotlin Gradle используйте блок plugins из DSL плагинов Gradle:

// replace `<...>` with the plugin name 
plugins {
    kotlin("<...>") version "1.7.20"
}
// replace `<...>` with the plugin name
plugins {
    id 'org.jetbrains.kotlin.<...>' version '1.7.20'
}

При настройке проекта проверьте совместимость плагина Kotlin Gradle с доступными версиями Gradle:

Минимальная поддерживаемая версия

Максимальная полностью поддерживаемая версия

Gradle

6.7.1

7.1.1

Android Gradle plugin

3.6.4

7.0.4

Например, плагин Kotlin Gradle и плагин kotlin-multiplatform 1.7.20 требуют минимальной версии Gradle 6.7.1 для компиляции вашего проекта.

В свою очередь, максимальная полностью поддерживаемая версия — 7.1.1. Она не содержит устаревших методов и свойств Gradle и поддерживает все текущие функции Gradle.

Настройка для нескольких платформ

Проекты, нацеленные на несколько платформ, называемые проектами для нескольких платформ, требуют плагин kotlin-multiplatform. Узнайте больше о плагине.

Плагин kotlin-multiplatform работает с Gradle 6.7.1 и новее.

plugins {
  kotlin("multiplatform") version "1.7.20"
}
plugins {
  id 'org.jetbrains.kotlin.multiplatform' version '1.7.20'
}
END_OF_DOCUMENT_MARKER

Настройка для JVM

Для настройки работы с JVM используйте плагин Kotlin JVM.

plugins {
    kotlin("jvm") version "1.7.20"
}
plugins {
    id "org.jetbrains.kotlin.jvm" version "1.7.20"
}

Этот version блок должен быть литеральным и не может быть применён из другого скрипта сборки.

В качестве альтернативы, можно использовать более старый подход apply plugin:

apply plugin: 'kotlin'

Применение плагинов Kotlin с apply в Kotlin Gradle DSL не рекомендуется – подробнее.

Kotlin и Java исходные файлы

Kotlin и Java исходные файлы можно хранить в одной папке или в разных. По умолчанию используются разные папки:

project
    - src
        - main (root)
            - kotlin
            - java

Соответствующее sourceSets свойство следует обновить, если вы используете не стандартную конвенцию:

sourceSets.main {
    java.srcDirs("src/main/myJava", "src/main/myKotlin")
}
sourceSets {
    main.kotlin.srcDirs += 'src/main/myKotlin'
    main.java.srcDirs += 'src/main/myJava'
}

Проверка совместимости JVM-таргета связанных задач компиляции

В модуле сборки могут быть связанные задачи компиляции, например:

  • compileKotlin и compileJava

  • compileTestKotlin и compileTestJava

Задачи компиляции наборов исходных файлов main и test не связаны.

Для таких связанных задач плагин Kotlin Gradle проверяет совместимость JVM-таргета. Разные значения jvmTarget в расширении kotlin и targetCompatibility в расширении java могут вызывать несовместимость. Например: задача compileKotlin имеет jvmTarget=1.8, а задача compileJava имеет (или унаследовано) targetCompatibility=15.

Управление поведением этой проверки осуществляется установкой свойства kotlin.jvm.target.validation.mode в файле build.gradle равным:

  • warning – значение по умолчанию; плагин Kotlin Gradle выведет сообщение об ошибке.

  • error – сборка завершится неудачно.

  • ignore – плагин пропустит проверку и не выведет никаких сообщений.

Связывание задач компилятора

Вы можете связать компиляции, установив такие отношения между ними, что одна компиляция будет использовать скомпилированные результаты другой. Связывание компиляций устанавливает internal видимость между ними.

Kotlin компилятор связывает некоторые компиляции по умолчанию, такие как test и main компиляции для каждого целевого объекта. Если вам нужно указать связь между пользовательскими компиляциями, создайте собственное связанное задание компиляции.

Для поддержки связанных компиляций в IDE для определения видимости между наборами исходных данных добавьте следующий код в свой build.gradle(.kts):

val integrationTestCompilation = kotlin.target.compilations.create("integrationTest") {
    associateWith(kotlin.target.compilations.getByName("main"))
}
integrationTestCompilation {
    kotlin.target.compilations.create("integrationTest") {
        associateWith(kotlin.target.compilations.getByName("main"))
    }
}

Здесь компиляция integrationTest связана с компиляцией main, что обеспечивает доступ к internal объектам из функциональных тестов.

Установить пользовательский JDK

По умолчанию задачи компиляции Kotlin используют текущий JDK Gradle. Если вам нужно изменить JDK по какой-либо причине, вы можете установить домашнюю директорию JDK с помощью Java toolchains или Task DSL для установки локального JDK.

Параметр компилятора jdkHome устарел начиная с Kotlin 1.5.30.

При использовании пользовательского JDK обратите внимание, что рабочие процессы kapt используют только режим изоляции процесса kapt.workers.isolation и игнорируют свойство kapt.workers.isolation.

Поддержка Gradle Java toolchains

Gradle 6.7 представил поддержку Java toolchains. Используя эту функцию, вы можете:

  • Использовать JDK и JRE, отличные от Gradle, для запуска компиляций, тестов и исполняемых файлов.

  • Компилировать и тестировать код с ещё не выпущенной версией языка.

С поддержкой toolchains Gradle может автоматически обнаруживать локальные JDK и устанавливать недостающие JDK, необходимые для сборки. Теперь сам Gradle может работать на любом JDK и по-прежнему использовать функцию кэша удалённых сборков для задач, зависящих от основной версии JDK.

Плагин Kotlin Gradle поддерживает Java toolchains для задач компиляции Kotlin/JVM. Задачи JS и Native не используют toolchains. Kotlin-компилятор всегда работает на JDK, на котором запущен Gradle-демон. Java toolchain:

  • Устанавливает опцию jdkHome, доступную для JVM-целей.

  • Устанавливает kotlinOptions.jvmTarget в версию JDK toolchain, если пользователь не установил опцию jvmTarget явно. Если пользователь не настраивает toolchain, поле jvmTarget будет использовать значение по умолчанию. Подробнее о совместимости JVM-таргета.

  • Устанавливает toolchain, который будет использоваться всеми задачами Java компиляции, тестирования и генерации javadoc.

  • Влияет на то, на каком JDK работают рабочие процессы kapt.

Используйте следующий код для установки toolchain. Замените <MAJOR_JDK_VERSION> на версию JDK, которую вы хотите использовать:

kotlin {
    jvmToolchain {
        languageVersion.set(JavaLanguageVersion.of(<MAJOR_JDK_VERSION>)) // "8" 
    }
}
kotlin {
    jvmToolchain {
        languageVersion.set(JavaLanguageVersion.of(<MAJOR_JDK_VERSION>)) // "8"
    }
}

Обратите внимание, что установка toolchain через расширение kotlin обновит toolchain и для задач Java компиляции.

Чтобы понять, какой toolchain использует Gradle, запустите сборку Gradle с уровнем логирования --info и найдите в выводе строку, начинающуюся с [KOTLIN] Kotlin compilation 'jdkHome' argument:. Часть после двоеточия будет версией JDK из toolchain.

Для установки любого JDK (даже локального) для конкретной задачи используйте Task DSL.

Установка версии JDK с помощью Task DSL

Task DSL позволяет установить любую версию JDK для любой задачи, реализующей интерфейс UsesKotlinJavaToolchain. На данный момент такими задачами являются KotlinCompile и KaptTask. Если вы хотите, чтобы Gradle искал основную версию JDK, замените <MAJOR_JDK_VERSION> в вашем скрипте сборки:

val service = project.extensions.getByType<JavaToolchainService>()
val customLauncher = service.launcherFor {
    it.languageVersion.set(JavaLanguageVersion.of(<MAJOR_JDK_VERSION>)) // "8"
}
project.tasks.withType<UsesKotlinJavaToolchain>().configureEach {
    kotlinJavaToolchain.toolchain.use(customLauncher)
}
JavaToolchainService service = project.getExtensions().getByType(JavaToolchainService.class)
Provider<JavaLauncher> customLauncher = service.launcherFor {
    it.languageVersion.set(JavaLanguageVersion.of(<MAJOR_JDK_VERSION>)) // "8"
}
tasks.withType(UsesKotlinJavaToolchain::class).configureEach { task ->
    task.kotlinJavaToolchain.toolchain.use(customLauncher)
}

Или вы можете указать путь к локальному JDK и заменить <LOCAL_JDK_VERSION> на эту версию JDK:

tasks.withType<UsesKotlinJavaToolchain>().configureEach {
    kotlinJavaToolchain.jdk.use(
        "/path/to/local/jdk", // Put a path to your JDK
        JavaVersion.<LOCAL_JDK_VERSION> // For example, JavaVersion.17
    )
}

Нацеливание на JavaScript

При нацеливании только на JavaScript используйте плагин kotlin-js. Узнать больше

plugins {
    kotlin("js") version "1.7.20"
}
plugins {
    id 'org.jetbrains.kotlin.js' version '1.7.20'
}

Kotlin и Java источники для JavaScript

Этот плагин работает только с файлами Kotlin, поэтому рекомендуется хранить файлы Kotlin и Java отдельно (если проект содержит Java файлы). Если вы не храните их отдельно, укажите папку с исходными файлами в блоке sourceSets:

kotlin {
    sourceSets["main"].apply {    
        kotlin.srcDir("src/main/myKotlin") 
    }
}
kotlin {
    sourceSets {
        main.kotlin.srcDirs += 'src/main/myKotlin'
    }
}

Нацеливание на Android

Рекомендуется использовать Android Studio для создания приложений для Android. Узнайте, как использовать плагин Android Gradle.

Настройка зависимостей

Для добавления зависимости от библиотеки установите зависимость требуемого типа (например, implementation) в блоке dependencies DSL-файла наборов исходных кодов.

kotlin {
    sourceSets {
        val commonMain by getting {
            dependencies {
                implementation("com.example:my-library:1.0")
            }
        }
    }
}
kotlin {
    sourceSets {
        commonMain {
            dependencies {
                implementation 'com.example:my-library:1.0'
            }
        }
    }
}

В качестве альтернативы можно указать зависимости на верхнем уровне.

Типы зависимостей

Выберите тип зависимости в соответствии с вашими потребностями.

Тип

Описание

Когда использовать

api

Используется как во время компиляции, так и во время выполнения и экспортируется потребителям библиотеки.

Если какой-либо тип из зависимости используется в общедоступном API текущего модуля, используйте зависимость типа api.

implementation

Используется во время компиляции и во время выполнения для текущего модуля, но не экспонируется для компиляции других модулей, зависящих от модуля с зависимостью `implementation`.

Используйте для зависимостей, необходимых для внутренней логики модуля.

Если модуль является конечной точкой приложения, которое не публикуется, используйте зависимости implementation вместо зависимостей api.

compileOnly

Используется для компиляции текущего модуля и недоступно во время выполнения или во время компиляции других модулей.

Используйте для API, для которого доступна реализация третьей стороны во время выполнения.

runtimeOnly

Доступно во время выполнения, но не видно во время компиляции любого модуля.

Зависимость от стандартной библиотеки

Зависимость от стандартной библиотеки (stdlib) автоматически добавляется к каждому набору исходных кодов. Версия стандартной библиотеки соответствует версии плагина Kotlin Gradle.

Для наборов исходных кодов, специфичных для платформы, используется соответствующая платформа-специфичная разновидность библиотеки, а для остальных добавляется общая стандартная библиотека. Плагин Kotlin Gradle выберет соответствующую стандартную библиотеку JVM в зависимости от kotlinOptions.jvmTarget параметра компилятора скрипта сборки Gradle.

Если вы явно объявляете зависимость от стандартной библиотеки (например, если вам нужна другая версия), плагин Kotlin Gradle её не переопределит и не добавит вторую стандартную библиотеку.

Если вам вообще не нужна стандартная библиотека, вы можете добавить опцию исключения в gradle.properties:

kotlin.stdlib.default.dependency=false

Установка зависимостей от библиотек тестов

API kotlin.test доступен для тестирования проектов Kotlin на всех поддерживаемых платформах. Добавьте зависимость kotlin-test к набору исходных кодов commonTest, и плагин Gradle определит соответствующие зависимости для каждого набора исходных кодов тестов:

  • kotlin-test-common и kotlin-test-annotations-common для общих наборов исходных кодов

  • kotlin-test-junit для наборов исходных кодов JVM

  • kotlin-test-js для наборов исходных кодов Kotlin/JS

Целевые платформы Kotlin/Native не требуют дополнительных зависимостей для тестов, и реализации API kotlin.test интегрированы.

kotlin {
    sourceSets {
        val commonTest by getting {
            dependencies {
                implementation(kotlin("test")) // This brings all the platform dependencies automatically
            }
        }
    }
}
kotlin {
    sourceSets {
        commonTest {
            dependencies {
                implementation kotlin("test") // This brings all the platform dependencies automatically
            }
        }
    }
}

Вы можете использовать сокращение для зависимости от модуля Kotlin, например, kotlin("test") для "org.jetbrains.kotlin:kotlin-test".

Вы можете использовать зависимость kotlin-test в любом общем или платформенно-специфичном наборе исходных кодов.

Для Kotlin/JVM Gradle по умолчанию использует JUnit 4. Поэтому зависимость kotlin("test") разрешается до варианта для JUnit 4, а именно kotlin-test-junit.

Вы можете выбрать JUnit 5 или TestNG, вызвав useJUnitPlatform() или useTestNG() в задаче тестирования скрипта сборки. Следующий пример для проекта Kotlin Multiplatform:

kotlin {
    jvm {
        testRuns["test"].executionTask.configure {
            useJUnitPlatform()
        }
    }
    sourceSets {
        val commonTest by getting {
            dependencies {
                implementation(kotlin("test"))
            }
        }
    }
}
kotlin {
    jvm {
        testRuns["test"].executionTask.configure {
            useJUnitPlatform()
        }
    }
    sourceSets {
        commonTest {
            dependencies {
                implementation kotlin("test")
            }
        }
    }
}

Следующий пример для проекта JVM:

dependencies {
    testImplementation(kotlin("test"))
}

tasks {
    test {
        useTestNG()
    }
}
dependencies {
    testImplementation 'org.jetbrains.kotlin:kotlin-test'
}

test {
    useTestNG()
}

Узнайте, как тестировать код с помощью JUnit на JVM.

Если вам нужно использовать другой фреймворк JVM для тестов, отключите автоматический выбор фреймворка, добавив строку kotlin.test.infer.jvm.variant=false в файл gradle.properties проекта. После этого добавьте фреймворк как зависимость Gradle.

Если вы явно использовали вариант kotlin("test") в скрипте сборки, и сборка проекта перестала работать из-за конфликта совместимости, ознакомьтесь с этим вопросом в руководстве по совместимости.

Установка зависимости на библиотеку kotlinx

Если вы используете библиотеку kotlinx и вам нужна платформа-специфичная зависимость, вы можете использовать платформенно-специфичные варианты библиотек с суффиксом, такими как -jvm или -js, например, kotlinx-coroutines-core-jvm. Также можно использовать имя базового артефакта библиотеки – kotlinx-coroutines-core.

kotlin {
    sourceSets {
        val jvmMain by getting {
            dependencies {
                implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core-jvm:1.6.4")
            }
        }
    }
}
kotlin {
    sourceSets {
        jvmMain {
            dependencies {
                implementation 'org.jetbrains.kotlinx:kotlinx-coroutines-core-jvm:1.6.4'
            }
        }
    }
}

Если вы используете многоплатформенную библиотеку и вам нужно зависеть от общего кода, установите зависимость только один раз в общем наборе исходных кодов. Используйте имя базового артефакта библиотеки, например, kotlinx-coroutines-core или ktor-client-core.

kotlin {
    sourceSets {
        val commonMain by getting {
            dependencies {
                implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:1.6.4")
            }
        }
    }
}
kotlin {
    sourceSets {
        commonMain {
            dependencies {
                implementation 'org.jetbrains.kotlinx:kotlinx-coroutines-core:1.6.4'
            }
        }
    }
}

Установка зависимостей на верхнем уровне

В качестве альтернативы вы можете указать зависимости на верхнем уровне, используя следующий шаблон для имён конфигураций: <sourceSetName><DependencyType>. Это может быть полезно для некоторых встроенных зависимостей Gradle, таких как gradleApi(), localGroovy() или gradleTestKit(), которые недоступны в DSL-файле зависимостей наборов исходных кодов.

dependencies {
    "commonMainImplementation"("com.example:my-library:1.0")
}
dependencies {
    commonMainImplementation 'com.example:my-library:1.0'
}

Обработка аннотаций

Kotlin поддерживает обработку аннотаций с помощью инструмента для обработки аннотаций Kotlin kapt.

Инкрементальная компиляция

Плагин Kotlin Gradle поддерживает инкрементальную компиляцию. Инкрементальная компиляция отслеживает изменения в исходных файлах между сборками, так что компилируются только файлы, затронутые этими изменениями.

Инкрементальная компиляция поддерживается для проектов Kotlin/JVM и Kotlin/JS и включена по умолчанию.

Существует несколько способов отключить инкрементальную компиляцию:

  • kotlin.incremental=false для Kotlin/JVM.

  • kotlin.incremental.js=false для проектов Kotlin/JS.

  • Используйте -Pkotlin.incremental=false или -Pkotlin.incremental.js=false в качестве параметра командной строки.

    Параметр должен быть добавлен в каждую последующую сборку, и любая сборка с отключённой инкрементальной компиляцией аннулирует кеши инкрементальной компиляции.

Первая сборка никогда не является инкрементальной.

Иногда проблемы с инкрементальной компиляцией становятся видны через несколько раундов после возникновения ошибки. Используйте отчеты о сборке, чтобы отслеживать историю изменений и компиляций. Это также может помочь вам предоставить воспроизводимые отчеты об ошибках.

Новый подход к инкрементальной компиляции

Новый подход к инкрементальной компиляции является экспериментальным. Он может быть удалён или изменён в любое время. Требуется включение (см. подробности ниже). Мы рекомендуем использовать его только для оценочных целей, и мы будем благодарны за ваши отзывы в YouTrack.

Новый подход к инкрементальной компиляции поддерживает изменения, внесённые внутри зависимых модулей, не являющихся Kotlin, включает улучшенное избегание компиляции и совместим с кешем сборки Gradle.

Все эти усовершенствования уменьшают количество неинкрементальных сборок, что ускоряет общее время компиляции. Наиболее значимый выигрыш от нового подхода ожидается, если вы используете кеш сборки или часто вносите изменения в не-Kotlin модули Gradle.

Чтобы включить этот новый подход, установите следующий параметр в своём gradle.properties:

kotlin.incremental.useClasspathSnapshot=true

Новый подход к инкрементальной компиляции доступен с Kotlin 1.7.0 для JVM-бекенда только в системе сборки Gradle.

Поддержка кеша сборки Gradle

Плагин Kotlin использует кеш сборки Gradle, который хранит выходные данные сборки для повторного использования в будущих сборках.

Чтобы отключить кеширование для всех задач Kotlin, установите системную переменную kotlin.caching.enabled в значение false (запустите сборку с аргументом -Dkotlin.caching.enabled=false).

Если вы используете kapt, обратите внимание, что задачи обработки аннотаций kapt по умолчанию не кэшируются. Однако вы можете включить кеширование для них вручную.

Поддержка кеша конфигурации Gradle

Поддержка кеша конфигурации Gradle имеет некоторые ограничения:

  • Кеш конфигурации доступен в Gradle 6.5 и более поздних версиях в качестве экспериментальной функции.
    Вы можете проверить страницу выпусков Gradle, чтобы узнать, стала ли она стабильной.

  • Функция поддерживается только следующими плагинами Gradle:

    • org.jetbrains.kotlin.jvm

    • org.jetbrains.kotlin.js

    • org.jetbrains.kotlin.android

Плагин Kotlin использует кеш конфигурации Gradle, что ускоряет процесс сборки, повторно используя результаты фазы конфигурации.

См. документацию Gradle, чтобы узнать, как включить кеш конфигурации. После включения этой функции плагин Kotlin Gradle будет автоматически использовать её.

Отчеты о сборке

Отчеты о сборке являются экспериментальными. Они могут быть удалены или изменены в любое время. Требуется включение (см. подробности ниже). Используйте их только для оценочных целей. Мы ценим ваши отзывы о них в YouTrack.

Отчеты о сборке для отслеживания производительности компилятора доступны для Kotlin 1.7.0. Отчеты содержат продолжительность различных фаз компиляции и причины, по которым компиляция не смогла быть инкрементальной.

Используйте отчеты о сборке для исследования проблем производительности, когда время компиляции слишком велико или отличается для одного и того же проекта.

Чтобы включить отчеты о сборке, укажите, куда сохранить выходные данные отчёта о сборке в gradle.properties:

kotlin.build.report.output=file

Доступны следующие значения и их комбинации для вывода:

Вариант

Описание

file

Сохраняет отчеты о сборке в локальном файле

build_scan

Сохраняет отчеты о сборке в разделе custom values отчета о сборке Gradle. Обратите внимание, что плагин Gradle Enterprise ограничен количеством пользовательских значений и их длиной. В больших проектах некоторые значения могут быть потеряны

http

Опубликовывает отчеты о сборке с помощью HTTP(S). Метод POST отправляет метрики в формате JSON. Вы можете увидеть текущую версию отправленных данных в репозитории Kotlin

Вот полный список доступных вариантов для kotlin.build.report:

# Required outputs. Any combinations are allowed
kotlin.build.report.output=file,http,build_scan

# Optional. Output directory for file-based reports. Default: build/reports/kotlin-build/
kotlin.build.report.file.output_dir=kotlin-reports

# Mandatory if http output is used. Where to post HTTP(S)-based reports
kotlin.build.report.http.url=http://127.0.0.1:8080

# Optional. User and password if the HTTP endpoint requires authentication
kotlin.build.report.http.user=someUser
kotlin.build.report.http.password=somePassword

# Optional. Label for marking your build report (e.g. debug parameters)
kotlin.build.report.label=some_label

Параметры компилятора

Используйте свойство kotlinOptions задачи компиляции Kotlin для указания дополнительных параметров компиляции.

При компиляции для JVM задачи называются compileKotlin для производственного кода и compileTestKotlin для тестового кода. Задачи для пользовательских наборов исходных кодов называются в соответствии с шаблонами compile<Name>Kotlin.

Имена задач в проектах Android содержат имена вариантов сборки и следуют шаблону compile<BuildVariant>Kotlin, например, compileDebugKotlin или compileReleaseUnitTestKotlin.

При компиляции для JavaScript задачи называются compileKotlinJs для производственного кода и compileTestKotlinJs для тестового кода, и compile<Name>KotlinJs для пользовательских наборов исходных кодов.

Чтобы настроить отдельную задачу, используйте её имя. Примеры:

import org.jetbrains.kotlin.gradle.tasks.KotlinCompile
// ...

val compileKotlin: KotlinCompile by tasks

compileKotlin.kotlinOptions.suppressWarnings = true
compileKotlin {
    kotlinOptions.suppressWarnings = true
}

//or

compileKotlin {
    kotlinOptions {
        suppressWarnings = true
    }
}

Обратите внимание, что в Gradle Kotlin DSL вы должны сначала получить задачу из tasks проекта.

Используйте типы Kotlin2JsCompile и KotlinCompileCommon для целей JS и common соответственно.

Также можно настроить все задачи компиляции Kotlin в проекте:

tasks.withType<org.jetbrains.kotlin.gradle.tasks.KotlinCompile>().configureEach {
    kotlinOptions { /*...*/ }
}
tasks.withType(org.jetbrains.kotlin.gradle.tasks.KotlinCompile).configureEach {
    kotlinOptions { /*...*/ }
}

Вот полный список параметров для задач Gradle:

Общие атрибуты для JVM, JS и JS DCE

Имя

Описание

Возможные значения

Значение по умолчанию

allWarningsAsErrors

Сообщать об ошибке, если есть предупреждения

false

suppressWarnings

Не генерировать предупреждения

false

verbose

Включить подробный вывод журнала. Работает только при включенном уровне отладки журнала Gradle

false

freeCompilerArgs

Список дополнительных аргументов компилятора

[]

Общие атрибуты для JVM и JS

Имя

Описание

Возможные значения

Значение по умолчанию

apiVersion

Ограничить использование объявлений теми, которые относятся к указанной версии встроенных библиотек

"1.3" (УСТАРЕЛО), "1.4" (УСТАРЕЛО), "1.5", "1.6", "1.7"

languageVersion

Обеспечить совместимость исходного кода с указанной версией Kotlin

"1.4" (УСТАРЕЛО), "1.5", "1.6", "1.7"

Атрибуты, специфичные для JVM

Имя

Описание

Возможные значения

Значение по умолчанию

javaParameters

Генерировать метаданные для отражения Java 1.8 на параметрах метода

false

jdkHome

Включить пользовательский JDK из указанного местоположения в classpath вместо JAVA_HOME по умолчанию. Прямая установка невозможна, используйте другие способы установки этого параметра.

jvmTarget

Целевая версия генерируемого байт-кода JVM

"1.8", "9", "10", ..., "18"

"1.8"

noJdk

Не включать автоматически среду выполнения Java в classpath

false

useOldBackend

Использовать старый бэкэнд JVM

false

Атрибуты, специфичные для JS

Имя

Описание

Возможные значения

Значение по умолчанию

friendModulesDisabled

Отключить экспорт внутренних объявлений

false

main

Определить, следует ли вызывать функцию main при выполнении

"call", "noCall"

"call"

metaInfo

Генерировать файлы .meta.js и .kjsm с метаданными. Используйте для создания библиотеки

true

moduleKind

Тип модуля JS, генерируемого компилятором

"umd", "commonjs", "amd", "plain"

"umd"

outputFile

Целевой файл *.js для результата компиляции

"<buildDir>/js/packages/<project.name>/kotlin/<project.name>.js"

sourceMap

Генерировать карту исходного кода

true

sourceMapEmbedSources

Встроить файлы исходного кода в карту исходного кода

"never", "always", "inlining"

sourceMapPrefix

Добавить указанный префикс к путям в карте исходного кода

target

Генерировать JS-файлы для конкретной версии ECMA

"v5"

"v5"

typedArrays

Преобразовать примитивные массивы в типизированные массивы JS

true

Генерация документации

Для генерации документации для проектов Kotlin используйте Dokka; пожалуйста, обратитесь к Dokka README для инструкций по конфигурации. Dokka поддерживает проекты на смешанных языках и может генерировать выходные данные в нескольких форматах, включая стандартный Javadoc.

OSGi

Для поддержки OSGi см. страницу Kotlin OSGi.

Использование Gradle Kotlin DSL

При использовании Gradle Kotlin DSL, применяйте плагины Kotlin, используя блок plugins { ... }. Если вы применяете их с помощью apply { plugin(...) }, вы можете столкнуться с неразрешёнными ссылками на расширения, сгенерированные Gradle Kotlin DSL. Чтобы решить эту проблему, вы можете закомментировать ошибочные использования, запустить задачу Gradle kotlinDslAccessorsSnapshot, а затем раскомментировать использования и повторно запустить сборку или повторно импортировать проект в IDE.

Kotlin-демон и его использование с Gradle

Kotlin-демон:

  • Работает вместе с демоном Gradle для компиляции проекта.

  • Работает отдельно, когда вы компилируете проект с интегрированной системой сборки IntelliJ IDEA.

Kotlin-демон запускается на стадии выполнения Gradle выполнения, когда одна из задач компиляции Kotlin начинает компиляцию исходных кодов. Kotlin-демон останавливается вместе с демоном Gradle или через два часа бездействия без компиляции Kotlin.

Kotlin-демон использует ту же JDK, что и демон Gradle.

Установка аргументов JVM для Kotlin-демона

Каждый из параметров в следующем списке переопределяет предыдущие:

  • Если ничего не указано, Kotlin-демон наследует аргументы от демона Gradle. Например, в файле gradle.properties:

    org.gradle.jvmargs=-Xmx1500m -Xms=500m
    
  • Если аргументы JVM демона Gradle имеют системную переменную kotlin.daemon.jvm.options – используйте её в файле gradle.properties:

    org.gradle.jvmargs=-Dkotlin.daemon.jvm.options=-Xmx1500m,Xms=500m
    

    При передаче аргументов следуйте этим правилам:

    • Используйте знак минус - перед аргументами Xmx, XX:MaxMetaspaceSize и XX:ReservedCodeCacheSize и не используйте его перед другими аргументами.

    • Разделяйте аргументы запятыми (,) без пробелов. Аргументы, следующие за пробелом, будут использованы для демона Gradle, а не для Kotlin-демона.

    Gradle игнорирует эти свойства, если выполняются все следующие условия:

    • Gradle использует JDK 1.9 или выше.

    • Версия Gradle находится в диапазоне от 7.0 до 7.1.1 включительно.

    • Gradle компилирует скрипты Kotlin DSL.

    • Kotlin-демон не запущен.

    Чтобы обойти это, обновите Gradle до версии 7.2 (или выше) или используйте свойство kotlin.daemon.jvmargs – см. следующий пункт.

  • Вы можете добавить свойство kotlin.daemon.jvmargs в файл gradle.properties:

    kotlin.daemon.jvmargs=-Xmx1500m -Xms=500m
    
  • Вы можете указать аргументы в расширении kotlin:

    kotlin {
        kotlinDaemonJvmArgs = listOf("-Xmx486m", "-Xms256m", "-XX:+UseParallelGC")
    }
    
    kotlin {
        kotlinDaemonJvmArgs = ["-Xmx486m", "-Xms256m", "-XX:+UseParallelGC"]
    }
    
  • Вы можете указать аргументы для конкретной задачи:

    tasks.withType<CompileUsingKotlinDaemon>().configureEach {
        kotlinDaemonJvmArguments.set(listOf("-Xmx486m", "-Xms256m", "-XX:+UseParallelGC"))
        }
    
    tasks.withType(CompileUsingKotlinDaemon::class).configureEach { task ->
        task.kotlinDaemonJvmArguments.set(["-Xmx1g", "-Xms512m"])
        }
    

    В этом случае новый экземпляр Kotlin-демона может запуститься при выполнении задачи. Подробнее об поведении Kotlin-демона с аргументами JVM.

Поведение Kotlin-демона с аргументами JVM

При настройке аргументов JVM Kotlin-демона обратите внимание на:

  • Ожидается, что несколько экземпляров Kotlin-демона будут работать одновременно, когда разные подпроекты или задачи имеют разные наборы аргументов JVM.

  • Новый экземпляр Kotlin-демона запускается только тогда, когда Gradle выполняет связанную задачу компиляции, а у существующих Kotlin-демонов нет одинакового набора аргументов JVM. Представьте, что ваш проект имеет много подпроектов. Большинство из них требуют определённого объёма памяти для Kotlin-демона, но один модуль требует много (хотя он редко компилируется). В этом случае вы должны предоставить другой набор аргументов JVM для такого модуля, чтобы Kotlin-демон с большим объёмом памяти запускался только для разработчиков, которые работают с этим конкретным модулем.

    Если вы уже запустили Kotlin-демона, у которого достаточно памяти для обработки запроса компиляции, даже если другие запрошенные аргументы JVM отличаются, этот демон будет повторно использован вместо запуска нового.

  • Если свойство Xmx не указано, Kotlin-демон унаследует его от демона Gradle.

Определение стратегии выполнения компилятора Kotlin

Стратегия выполнения компилятора Kotlin определяет место выполнения компилятора Kotlin и поддерживается ли инкрементная компиляция в каждом случае.

Существует три стратегии выполнения компилятора:

Стратегия

Где выполняется компилятор Kotlin

Инкрементная компиляция

Другие характеристики и заметки

Демон

Внутри собственного демона процесса

Да

По умолчанию и самая быстрая стратегия. Может быть совместно использована между различными демонами Gradle и несколькими параллельными компиляциями.

В процессе

Внутри процесса демона Gradle

Нет

Может использовать кучу вместе с демоном Gradle. Стратегия выполнения «В процессе» медленнее, чем стратегия «Демон». Каждый работник создаёт отдельный класс загрузчик компилятора Kotlin для каждой компиляции.

Вне процесса

В отдельном процессе для каждой компиляции

Нет

Самая медленная стратегия выполнения. Аналогична «В процессе», но дополнительно создаёт отдельный Java-процесс внутри Gradle-работника для каждой компиляции.

Чтобы определить стратегию выполнения компилятора Kotlin, вы можете использовать одно из следующих свойств:

  • Свойство Gradle kotlin.compiler.execution.strategy.

  • Свойство задачи компиляции compilerExecutionStrategy.

  • Устаревшее свойство -Dkotlin.compiler.execution.strategy, которое будет удалено в будущих выпусках.

Приоритет свойств следующий:

  • Свойство задачи compilerExecutionStrategy имеет приоритет над системным свойством и свойством Gradle kotlin.compiler.execution.strategy.

  • Свойство Gradle имеет приоритет над системным свойством.

Доступные значения для свойств kotlin.compiler.execution.strategy (как системных, так и Gradle) следующие:

  1. daemon (по умолчанию)

  2. in-process

  3. out-of-process

Используйте свойство Gradle kotlin.compiler.execution.strategy в gradle.properties:

kotlin.compiler.execution.strategy=out-of-process

Доступные значения для свойства задачи compilerExecutionStrategy следующие:

  1. org.jetbrains.kotlin.gradle.tasks.KotlinCompilerExecutionStrategy.DAEMON (по умолчанию)

  2. org.jetbrains.kotlin.gradle.tasks.KotlinCompilerExecutionStrategy.IN_PROCESS

  3. org.jetbrains.kotlin.gradle.tasks.KotlinCompilerExecutionStrategy.OUT_OF_PROCESS

Используйте свойство задачи compilerExecutionStrategy в ваших скриптах сборки:

import org.jetbrains.kotlin.gradle.tasks.KotlinCompile
import org.jetbrains.kotlin.gradle.tasks.KotlinCompilerExecutionStrategy

// ...

tasks.withType<KotlinCompile>().configureEach {
    compilerExecutionStrategy.set(KotlinCompilerExecutionStrategy.IN_PROCESS)
} 
import org.jetbrains.kotlin.gradle.tasks.KotlinCompile
import org.jetbrains.kotlin.gradle.tasks.KotlinCompilerExecutionStrategy

// ...

tasks.withType(KotlinCompile)
    .configureEach {
         compilerExecutionStrategy.set(KotlinCompilerExecutionStrategy.IN_PROCESS)
    }

Выполнение действий конфигурации с интерфейсом KotlinBasePlugin

Чтобы выполнить какое-либо действие конфигурации всякий раз, когда применяется любой плагин Kotlin Gradle (JVM, JS, Multiplatform, Native и другие), используйте интерфейс KotlinBasePlugin, который унаследован от всех плагинов Kotlin:

import org.jetbrains.kotlin.gradle.plugin.KotlinBasePlugin

// ...

project.plugins.withType<KotlinBasePlugin>() {
// Configure your action here
}
import org.jetbrains.kotlin.gradle.plugin.KotlinBasePlugin

// ...

project.plugins.withType(KotlinBasePlugin.class) {
// Configure your action here
}
Последнее изменение: 29 сентября 2022 г.
Ключевые слова и операторы Maven

© 2010–2022 JetBrains s.r.o. and Kotlin Programming Language contributors
Licensed under the Apache License, Version 2.0.
https://kotlinlang.org/docs/gradle.html

Spec-Zone.ru

Настройки Оффлайн Что нового Помощь О нас
Spec-Zone .ru
спецификации, руководства, описания, API