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. Узнайте больше о плагине.
plugins {
kotlin("multiplatform") version "1.7.20"
}
plugins {
id 'org.jetbrains.kotlin.multiplatform' version '1.7.20'
}
Настройка для 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иcompileJavacompileTestKotlinиcompileTestJava
Для таких связанных задач плагин 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.
При использовании пользовательского 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 компиляции.
Для установки любого 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 текущего модуля, используйте зависимость типа |
|
Используется во время компиляции и во время выполнения для текущего модуля, но не экспонируется для компиляции других модулей, зависящих от модуля с зависимостью `implementation`. |
Используйте для зависимостей, необходимых для внутренней логики модуля. Если модуль является конечной точкой приложения, которое не публикуется, используйте зависимости |
|
Используется для компиляции текущего модуля и недоступно во время выполнения или во время компиляции других модулей. |
Используйте для API, для которого доступна реализация третьей стороны во время выполнения. |
|
Доступно во время выполнения, но не видно во время компиляции любого модуля. |
Зависимость от стандартной библиотеки
Зависимость от стандартной библиотеки (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для наборов исходных кодов JVMkotlin-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-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в качестве параметра командной строки.Параметр должен быть добавлен в каждую последующую сборку, и любая сборка с отключённой инкрементальной компиляцией аннулирует кеши инкрементальной компиляции.
Первая сборка никогда не является инкрементальной.
Новый подход к инкрементальной компиляции
Новый подход к инкрементальной компиляции поддерживает изменения, внесённые внутри зависимых модулей, не являющихся Kotlin, включает улучшенное избегание компиляции и совместим с кешем сборки Gradle.
Все эти усовершенствования уменьшают количество неинкрементальных сборок, что ускоряет общее время компиляции. Наиболее значимый выигрыш от нового подхода ожидается, если вы используете кеш сборки или часто вносите изменения в не-Kotlin модули Gradle.
Чтобы включить этот новый подход, установите следующий параметр в своём gradle.properties:
kotlin.incremental.useClasspathSnapshot=true
Поддержка кеша сборки Gradle
Плагин Kotlin использует кеш сборки Gradle, который хранит выходные данные сборки для повторного использования в будущих сборках.
Чтобы отключить кеширование для всех задач Kotlin, установите системную переменную kotlin.caching.enabled в значение false (запустите сборку с аргументом -Dkotlin.caching.enabled=false).
Если вы используете kapt, обратите внимание, что задачи обработки аннотаций kapt по умолчанию не кэшируются. Однако вы можете включить кеширование для них вручную.
Поддержка кеша конфигурации Gradle
Плагин Kotlin использует кеш конфигурации Gradle, что ускоряет процесс сборки, повторно используя результаты фазы конфигурации.
См. документацию Gradle, чтобы узнать, как включить кеш конфигурации. После включения этой функции плагин Kotlin Gradle будет автоматически использовать её.
Отчеты о сборке
Отчеты о сборке для отслеживания производительности компилятора доступны для Kotlin 1.7.0. Отчеты содержат продолжительность различных фаз компиляции и причины, по которым компиляция не смогла быть инкрементальной.
Используйте отчеты о сборке для исследования проблем производительности, когда время компиляции слишком велико или отличается для одного и того же проекта.
Чтобы включить отчеты о сборке, укажите, куда сохранить выходные данные отчёта о сборке в gradle.properties:
kotlin.build.report.output=file
Доступны следующие значения и их комбинации для вывода:
Вариант |
Описание |
|
|---|---|---|
|
Сохраняет отчеты о сборке в локальном файле |
|
|
Сохраняет отчеты о сборке в разделе |
|
|
Опубликовывает отчеты о сборке с помощью 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
Имя |
Описание |
Возможные значения |
Значение по умолчанию |
|---|---|---|---|
|
Сообщать об ошибке, если есть предупреждения |
false |
|
|
Не генерировать предупреждения |
false |
|
|
Включить подробный вывод журнала. Работает только при включенном уровне отладки журнала Gradle |
false |
|
|
Список дополнительных аргументов компилятора |
[] |
Общие атрибуты для JVM и JS
Имя |
Описание |
Возможные значения |
Значение по умолчанию |
|---|---|---|---|
|
Ограничить использование объявлений теми, которые относятся к указанной версии встроенных библиотек |
"1.3" (УСТАРЕЛО), "1.4" (УСТАРЕЛО), "1.5", "1.6", "1.7" |
|
|
Обеспечить совместимость исходного кода с указанной версией Kotlin |
"1.4" (УСТАРЕЛО), "1.5", "1.6", "1.7" |
Атрибуты, специфичные для JVM
Имя |
Описание |
Возможные значения |
Значение по умолчанию |
|---|---|---|---|
|
Генерировать метаданные для отражения Java 1.8 на параметрах метода |
false |
|
|
Включить пользовательский JDK из указанного местоположения в classpath вместо JAVA_HOME по умолчанию. Прямая установка невозможна, используйте другие способы установки этого параметра. |
||
|
Целевая версия генерируемого байт-кода JVM |
"1.8", "9", "10", ..., "18" |
"1.8" |
|
Не включать автоматически среду выполнения Java в classpath |
false |
|
|
Использовать старый бэкэнд JVM |
false |
Атрибуты, специфичные для JS
Имя |
Описание |
Возможные значения |
Значение по умолчанию |
|---|---|---|---|
|
Отключить экспорт внутренних объявлений |
false |
|
|
Определить, следует ли вызывать функцию |
"call", "noCall" |
"call" |
|
Генерировать файлы .meta.js и .kjsm с метаданными. Используйте для создания библиотеки |
true |
|
|
Тип модуля JS, генерируемого компилятором |
"umd", "commonjs", "amd", "plain" |
"umd" |
|
Целевой файл *.js для результата компиляции |
"<buildDir>/js/packages/<project.name>/kotlin/<project.name>.js" |
|
|
Генерировать карту исходного кода |
true |
|
|
Встроить файлы исходного кода в карту исходного кода |
"never", "always", "inlining" |
|
|
Добавить указанный префикс к путям в карте исходного кода |
||
|
Генерировать JS-файлы для конкретной версии ECMA |
"v5" |
"v5" |
|
Преобразовать примитивные массивы в типизированные массивы 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-демона.
-
Вы можете добавить свойство
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-демона с аргументами JVM
При настройке аргументов JVM Kotlin-демона обратите внимание на:
Ожидается, что несколько экземпляров Kotlin-демона будут работать одновременно, когда разные подпроекты или задачи имеют разные наборы аргументов JVM.
-
Новый экземпляр Kotlin-демона запускается только тогда, когда Gradle выполняет связанную задачу компиляции, а у существующих Kotlin-демонов нет одинакового набора аргументов JVM. Представьте, что ваш проект имеет много подпроектов. Большинство из них требуют определённого объёма памяти для Kotlin-демона, но один модуль требует много (хотя он редко компилируется). В этом случае вы должны предоставить другой набор аргументов JVM для такого модуля, чтобы Kotlin-демон с большим объёмом памяти запускался только для разработчиков, которые работают с этим конкретным модулем.
Если свойство
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имеет приоритет над системным свойством и свойством Gradlekotlin.compiler.execution.strategy.Свойство Gradle имеет приоритет над системным свойством.
Доступные значения для свойств kotlin.compiler.execution.strategy (как системных, так и Gradle) следующие:
daemon(по умолчанию)in-processout-of-process
Используйте свойство Gradle kotlin.compiler.execution.strategy в gradle.properties:
kotlin.compiler.execution.strategy=out-of-process
Доступные значения для свойства задачи compilerExecutionStrategy следующие:
org.jetbrains.kotlin.gradle.tasks.KotlinCompilerExecutionStrategy.DAEMON(по умолчанию)org.jetbrains.kotlin.gradle.tasks.KotlinCompilerExecutionStrategy.IN_PROCESSorg.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
}
© 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