Configure a Gradle project

그레이들로 코틀린 프로젝트를 빌드하려면 빌드 스크립트 파일 build.gradle(.kts)코틀린 그레이들 플러그인을 추가하고 거기에서 프로젝트의 의존성을 구성해야 한다.

빌드 스크립트의 내용을 자세히 알아보려면, 빌드 스크립트 살펴보기를 방문하자.

Apply the plugin

코틀린 그레이들 플러그인을 적용하려면, 그레이들 플러그인 DSL의 plugins 블록을 사용하자:

코틀린

// `<...>`를 플러그인 명으로 변경하자
plugins {
    kotlin("<...>") version "1.9.0"
}

그루비

// `<...>`를 플러그인 명으로 변경하자
plugins {
    id 'org.jetbrains.kotlin.<...>' version '1.9.0'
}

코틀린 그레이들 플러그인(KGP)과 코틀린은 동일한 버전 번호를 공유한다.

프로젝트를 구성할 때, 사용 가능한 그레이들 버전과 코틀린 그레이들 플러그인(KGP) 호환성을 확인하자. 다음 표에는 그레이들 및 안드로이드 그레이들 플러그인(AGP)의 최소 및 최대 지원 버전이 나와 있다:

KGP 버전그레이들의 최소 최대 버전AGP의 최소 최대 버전
1.9.06.8.3 – 7.6.04.2.2 – 7.4.0
1.8.206.8.3 – 7.6.04.1.3 – 7.4.0
1.8.06.8.3 – 7.3.34.1.3 – 7.2.1
1.7.206.7.1 – 7.1.13.6.4 – 7.0.4
1.7.06.7.1 – 7.0.23.4.3 – 7.0.2
1.6.206.1.1 - 7.0.23.4.3 - 7.0.2

그레이들 및 AGP 버전을 최신 릴리스까지 사용할 수도 있지만, 그렇게 하는 경우 지원 중단 경고가 표시되거나 일부 새로운 기능이 작동하지 않을 수 있다.

예를 들어, 코틀린 그레이들 플러그인 및 kotlin-multiplatform 플러그인 1.9.0은 프로젝트를 컴파일하려면 최소 그레이들 버전 6.8.3이 필요하다.

마찬가지로, 완전히 지원되는 최대 버전은 7.6.0이다. 더 이상 사용되지 않는 그레이들 메서드 및 프로퍼티는 없으며 현재 모튼 그레이들 기능을 지원한다.

Targeting the JVM

JVM을 대상으로 하려면 코틀린 JVM 플러그인을 적용한다.

코틀린

  plugins {
    kotlin("jvm") version "1.9.0"
  }

그루비

  plugins {
    id "org.jetbrains.kotlin.jvm" version "1.9.0"
  }

version은 이 블록에서만 읽혀야 하며, 다른 빌드 스크립트에서 적용할 수 없다.

Kotlin and Java sources

코틀린 소스와 자바 소스는 ​​동일한 디렉토리에 저장하거나, 다른 디렉토리에 배치할 수 있다.

기본 컨벤션은 다른 디렉토리를 사용하는 것이다:

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

자바.java 파일은 컴파일되지 않으므로, src/*/kotlin 디렉토리에 .java 파일을 저장하지 말자. 대신, src/main/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'
  }

빌드 모듈에는, 관련 컴파일 태스크가 있을 수 있다. 예를 들어:

  • compileKotlin and compileJava
  • compileTestKotlin and compileTestJava

maintest source set 컴파일 태스크는 관련 없다.

이와 같은 태스크의 경우, 코틀린 그레이들 플러그인은 JVM 대상 호환성을 확인한다. kotlin extention 또는 태스크의 jvmTarget 애트리뷰트 값과 java extention 또는 태스크의 targetCompatibility 값이 다르면 JVM 대상 비호환성이 발생한다. 예: compileKotlin 태스크는 jvmTarget=1.8이고, compileJava태스크는 targetCompatibility=15를 갖거나 상속한다.

build.gradle(.kts) 파일의 kotlin.jvm.target.validation.mode 프로퍼티를 다음과 같이 설정하여 전체 프로젝트에 대한 이 검사 동작을 구성한다:

  • error – 플러그인이 빌드에 실패한다; 그레이들 8.0+(버전)의 프로젝트에 대한 기본값.
  • warning – 플러그인은 경고 메시지를 출력한다; 8.0 미만(버전)의 그레이들 프로젝트에 대한 기본값
  • ignore – 플러그인은 확인을 건너뛰고 메시지를 생성하지 않는다.

build.gradle(.kts) 파일의 태스크 레벨에서 구성할 수도 있다:

코틀린

  tasks.withType<org.jetbrains.kotlin.gradle.tasks.KotlinJvmCompile>().configureEach {
    jvmTargetValidationMode.set(org.jetbrains.kotlin.gradle.dsl.jvm.JvmTargetValidationMode.WARNING)
  }

그루비

  tasks.withType(org.jetbrains.kotlin.gradle.tasks.KotlinJvmCompile.class).configureEach {
    jvmTargetValidationMode = org.jetbrains.kotlin.gradle.dsl.jvm.JvmTargetValidationMode.WARNING
  }

JVM 비호환성을 방지하려면, 툴체인(tool chanin)을 구성하거나 JVM 버전을 수동으로 설정하자.

대상 호환성을 확인하지 않으면 무엇이 잘못될 수 있나?

코틀린 및 자바 source set에 대한 JVM 대상을 수동으로 설정하는 두 가지 방법이 있다:

  • 자바 툴체인 설정을 통한 암시적 방법.
  • 코틀린 익스텐션(kotlin extention) 또는 태스크에서 jvmTarget 애트리뷰트을 설정하고 자바 익스텐션(java extention) 또는 태스크에서 targetCompatibility를 설정하는 명시적 방법.

다음과 같은 경우 JVM 비호환성이 발생한다:

  • jvmTargettargetCompatibility의 다른 값을 명시적으로 설정.
  • 기본 구성이 있고, JDK가 1.8이 아니다.

빌드 스크립트에 코틀린 JVM 플러그인만 있고 JVM 대상에 대한 추가 설정이 없는 경우 JVM 대상의 기본 구성을 고려해 보자:

코틀린

  plugins {
    kotlin("jvm") version "1.9.0"
  }

그루비

  plugins {
    id "org.jetbrains.kotlin.jvm" version "1.9.0"
  }

빌드 스크립트에 jvmTarget 값에 대한 명시적인 정보가 없는 경우 기본값은 null이며, 컴파일러는 이를 기본값 1.8로 변환한다. targetCompatibility는 JDK 버전과 동일한 현재 그레이들의 JDK 버전(자바 툴체인 접근 방식을 사용하지 않는 한)과 같다. JDK 버전이 17이라고 가정하면, 게시된 라이브러리 아티팩트가 JDK 17+와 호환된다고 선언(org.gradle.jvm.version=17)하는데, 이는 잘못된 것이다. 이 경우 바이트 코드의 버전이 1.8인 경우에도 이 라이브러리를 추가하려면 기본 프로젝트에서 Java 17을 사용해야 한다. 이 문제를 해결하기 위해 툴체인(toolchain)을 구성해야 한다.

Gradle Java toolchains support

안드로이드 사용자를 위한 경고이다. 그레이들 툴체인을 사용하려면, 안드로이드 그레이들 플러그인(AGP) 버전 8.1.0-alpha09 이상을 사용해야 한다.

그레이들 자바 툴체인 지원은 AGP 7.4.0에서만 사용할 수 있다. 그럼에도 불구하고, 이 문제로 인해, AGP는 8.1.0-alpha09 버전이 나올 때까지, targetCompatibility를 툴체인의 JDK와 동일하게 설정하지 않았다. 8.1.0-alpha09 미만 버전을 사용하는 경우 compileOptions를 통해 targetCompatibility를 수동으로 구성해야 한다. 을 사용하려는 JDK 버전으로 바꾸자:

android {
    compileOptions {
        sourceCompatibility = <MAJOR_JDK_VERSION>
        targetCompatibility = <MAJOR_JDK_VERSION>
    }
}

그레이들 6.7은 자바 툴체인을 지원한다. 이 기능을 사용하여 다음을 수행할 수 있다:

  • 그레이들과 다른 JDK 및 JRE를 사용하여 컴파일, 테스트 및 실행 파일을 실행한다.
  • 아직 릴리스되지 않은 언어 버전으로 코드 컴파일 및 테스트한다.

툴체인 지원을 통해, 그레이들은 로컬 JDK를 자동 감지하고 그레이들이 빌드에 필요한 누락된 JDK를 설치할 수 있다. 이제 그레이들 자체는 모든 JDK에서 실행될 수 있으며 여전히 메이저(major) JDK 버전에 의존하는 태스크에 대해 원격 빌드 캐시 기능을 재사용할 수 있다.

코틀린 그레이들 플러그인은 코틀린/JVM 컴파일 작업을 위한 자바 툴체인을 지원한다. JS 및 네이티브(Native) 작업은 툴체인을 사용하지 않는다. 코틀린 컴파일러는 항상 그레이들 데몬이 실행 중인 JDK에서 실행된다:

  • JVM 대상에 사용할 수 있는 -jdk-home 옵션을 설정한다.
  • 사용자가 jvmTarget 옵션을 명시적으로 설정하지 않은 경우 compilerOptions.jvmTarget을 툴체인의 JDK 버전으로 설정한다. 사용자가 툴체인을 구성하지 않는 경우 jvmTarget 필드는 기본값을 사용한다. JVM 대상 호환성에 대해 자세히 알아보자.

  • 자바 컴파일, 테스트 및 자바독(javadoc) 태스크에서 사용할 도구 모음을 설정한다.

  • 실행 중인 JDK kapt 워커에 영향을 미친다.

다음 코드를 사용하여 도구 체인을 설정하자. 을 사용하려는 JDK 버전으로 바꾸자:

코틀린

  kotlin {
    jvmToolchain {
        languageVersion.set(JavaLanguageVersion.of(<MAJOR_JDK_VERSION>))
    }
    // 또는 줄여서:
    jvmToolchain(<MAJOR_JDK_VERSION>)
    // 예시:
    jvmToolchain(17)
  }

그루비

  kotlin {
    jvmToolchain {
        languageVersion.set(JavaLanguageVersion.of(<MAJOR_JDK_VERSION>))
    }
    // 또는 줄여서:
    jvmToolchain(<MAJOR_JDK_VERSION>)
    // 예시:
    jvmToolchain(17) 
  }

코틀린 익스텐션을 통해 툴체인을 설정하면 자바 컴파일 태스크 툴체인도 업데이트된다.

자바 익스텐션을 통해 툴체인을 설정할 수 있으며, 코틀린 컴파일 태스크에서 이를 사용한다:

코틀린

  java {
    toolchain {
        languageVersion.set(JavaLanguageVersion.of(<MAJOR_JDK_VERSION>))
    }
  }

그루비

  java {
    toolchain {
        languageVersion.set(JavaLanguageVersion.of(<MAJOR_JDK_VERSION>))
    }
  }

그레이들 8.0.2 이상을 사용하는 경우, toolchain resolver 플러그인도 추가해야 한다. 이 유형의 플러그인은 툴체인을 다운로드할 리포지터리를 관리한다. 예를 들어, settings.gradle(.kts)에 다음 플러그인을 추가한다:

코틀린

plugins {
  id("org.gradle.toolchains.foojay-resolver-convention") version("0.5.0")
}

그루비

plugins {
  id 'org.gradle.toolchains.foojay-resolver-convention' version '0.5.0'
}

foojay-resolver-convention의 버전이 그레이들 사이트의 그레이들 버전과 일치하는지 확인하자.

그레이들이 사용하는 툴체인을 이해하려면 로그 수준을 –info로 그레이들 빌드를 실행하고 출력에서 ​​[KOTLIN] Kotlin compilation 'jdkHome' argument:로 시작하는 문자열을 찾아보자. 콜론(:) 뒤의 부분은 툴체인의 JDK 버전이다.

특정 태스크에 대해 JDK(로컬 포함)를 설정하려면, 태스크 DSL을 사용하자.

코틀린 플러그인에서 그레이들 JVM 툴체인에 대해 자세히 알아보기.

Set JDK version with the Task DSL

태스크 DSL을 사용하면 UsesKotlinJavaToolchain 인터페이스를 구현하는 모든 태스크에 대해 모든 JDK 버전을 설정할 수 있다. 현재 이러한 태스크는은 KotlinCompileKaptTask이다. 그레이들이 메이저(major) JDK 버전을 검색하도록 하려면 빌드 스크립트에서 를 바꾸자.

코틀린

  val service = project.extensions.getByType<JavaToolchainService>()
  val customLauncher = service.launcherFor {
    languageVersion.set(JavaLanguageVersion.of(<MAJOR_JDK_VERSION>))
  }
  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>))
  }
  tasks.withType(UsesKotlinJavaToolchain::class).configureEach { task ->
    task.kotlinJavaToolchain.toolchain.use(customLauncher)
  }

또는 로컬 JDK에 대한 경로를 지정하고 을 이 JDK 버전으로 바꿀 수 있다:

  tasks.withType<UsesKotlinJavaToolchain>().configureEach {
    kotlinJavaToolchain.jdk.use(
        "/path/to/local/jdk", // JDK 패스 입력
        JavaVersion.<LOCAL_JDK_VERSION> // 예, JavaVersion.17
    )
  }

Associate compiler tasks

하나의 컴파일이 다른 컴파일된 출력을 사용하는 것과 같은 관계를 설정하여 컴파일을 연결할 수 있다. 컴파일을 연결하면 컴파일 간에 내부(internal) 가시성이 형성된다.

코틀린 컴파일러는 기본적으로, 각 대상의 테스트메인 컴파일과 같은 일부 컴파일을 연결한다. 커스텀 컴파일 중 하나가 다른 컴파일에 연결되어 있음을 표현해야 하는 경우, 연결된 compilations을 직접 만들자.

IDE가 source set 간 가시성을 유추하기 위해, 연결된 컴파일을 지원하도록 하려면 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 컴파일은 기능 테스트에서 내부 개체에 대한 접근를 제공하는 메인 컴파일과 연결된다.

Configure with Java Modules (JPMS) enabled

코틀린 그레이들 플러그인이 자바 모듈과 함께 작동하도록 하려면, 빌드 스크립트에 다음 줄을 추가하고 YOUR_MODULE_NAME을 JPMS 모듈에 대한 참조(예: org.company.module)로 바꾼다:

코틀린

// 7.0 미만의 Gradle 버전을 사용하는 경우 아래 세 줄을 추가하자.
java {
    modularity.inferModulePath.set(true)
}

tasks.named("compileJava", JavaCompile::class.java) {
    options.compilerArgumentProviders.add(CommandLineArgumentProvider {
        // 컴파일된 코틀린 클래스를 javac에 제공 – 자바/코틀린 혼합 소스가 작동하는 데 필요하다.
        listOf("--patch-module", "YOUR_MODULE_NAME=${sourceSets["main"].output.asPath}")
    })
}

그루비

// 7.0 미만의 Gradle 버전을 사용하는 경우 아래 세 줄을 추가하자.
java {
    modularity.inferModulePath = true
}

tasks.named("compileJava", JavaCompile.class) {
    options.compilerArgumentProviders.add(new CommandLineArgumentProvider() {
        @Override
        Iterable<String> asArguments() {
            // 컴파일된 코틀린 클래스를 javac에 제공 – 자바/코틀린 혼합 소스가 작동하는 데 필요하다.
            return ["--patch-module", "YOUR_MODULE_NAME=${sourceSets["main"].output.asPath}"]
        }
    })
}

일반적이게, module-info.java를 src/main/java 디렉토리에 넣는다. 모듈의 경우, “패키지가 비어 있거나 존재하지 않음” 빌드 실패를 방지하려면 코틀린 파일의 패키지 이름이 module-info.java의 패키지 이름과 같아야 한다.

좀 더 배워보자:

Other details

Kotlin/JVM에 대해 자세히 알아보기.

Lazy Kotlin/JVM 태스크 생성

코틀린 1.8.20부터, 코틀린 그레이들 플러그인은 모든 태스크를 등록하고 드라이 런(dry run)에서 구성하지 않는다.

컴파일 태스크의 destinationDirectory의 일반적이지 않은 위치

Kotlin/JVM KotlinJvmCompile/KotlinCompile 태스크의 destinationDirectory 위치를 오버라이드(override)하는 경우 빌드 스크립트를 업데이한다. JAR 파일의 sourceSets.main.outputssourceSets.main.kotlin.classesDirectories를 명시적으로 추가해야 한다:

  tasks.jar(type: Jar) {
     from sourceSets.main.outputs
     from sourceSets.main.kotlin.classesDirectories
  }

Targeting multiple platforms

멀티플랫폼 프로젝트라고 하는, 멀티플 플랫폼을 대상으로 하는 프로젝트에는, kotlin-multiplatform 플러그인이 필요하다. 플러그인에 대해 자세히 알아보기

kotlin-multiplatform 플러그인은 Gradle 6.8.3 이상에서 작동한다.

코틀린

  plugins {
    kotlin("multiplatform") version "1.9.0"
  }

그루비

  plugins {
    id 'org.jetbrains.kotlin.multiplatform' version '1.9.0'
  }

다양한 플랫폼용 Kotlin MultiplatformiOS 및 Android용 Kotlin Multiplatform에 대해 자세히 알아보자.

Targeting Android

안드로이드 애플리케이션을 만들려면 안드로이드 스튜디오를 사용하는 것이 좋다. 안드로이드 그레이들 플러그인 사용 방법을 알아보자.

Targeting JavaScript

자바스크립트를 대상으로 할 때, kotlin-multiplatform 플러그인도 사용하자. Kotlin/JS 프로젝트 설정에 대해 자세히 알아보자.

코틀린

  plugins {
    kotlin("multiplatform") version "1.9.0"
  }

그루비

  plugins {
    id 'org.jetbrains.kotlin.multiplatform' version '1.9.0'
  }

Kotlin and Java sources for JavaScript

이 플러그인은 코틀린 파일에서만 작동하므로 코틀린과 자바 파일(프로젝트에 자바 파일이 포함된 경우)을 별도로 유지하는 것이 좋다. 별도로 저장하지 않은 경우, sourceSets 블록에 소스 폴더 지정하자:

코틀린

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

그루비

  kotlin {
   sourceSets {
        main.kotlin.srcDirs += 'src/main/myKotlin'
    }
  }

Triggering configuration actions with the KotlinBasePlugin interface

코틀린 그레이들 플러그인(JVM, JS, Multiplatform, Native 등)이 적용될 때마다 일부 구성 작업을 트리거하려면, 모든 코틀린 플러그인이 상속하는 KotlinBasePlugin 인터페이스를 사용하자.

코틀린

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

// ...

project.plugins.withType<KotlinBasePlugin>() {
    // 여기에 작업 구성
}

그루비

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

// ...

project.plugins.withType(KotlinBasePlugin.class) {
    // 여기에 작업 구성
}

Configure dependencies

라이브러리에 대한 의존성을 추가하려면, source set DSL의 dependencies 블록에서 필요한 유형(예: implementation)의 의존성을 설정한다.

코틀린

  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'
        }
      }
    }
  } 

또는, 최상위 수준에서 의존성을 설정할 수 있다.

Dependency types

요구 사항에 따라 의존성 유형을 선택하자.

TypeDescriptionWhen to use
api컴파일과 런타임에 모두 사용되며 라이브러리 소비자에게 노출된다.의존성의 유형이 현재 모듈에서 공개 API로 사용되는 경우, api 의존성을 사용하자.
implementation컴파일 및 런타임 시 현재 모듈에 사용되지만, implementation 의존성이 있는 모듈에 따라 다른 모듈의 컴파일에는 노출되지 않는다.모듈의 내부 로직에 필요한 의존성일 경우 사용한다. 모듈이 게시되지 않은 엔드포인트 애플리케이션인 경우 API 의존성 대신 implementation 의존성을 사용해야한다.
compileOnly현재 모듈의 컴파일 시 사용되며 런타임이나 다른 모듈의 컴파일 중에는 사용할 수 없다.런타임에 사용할 수 있는 서드-파티 구현이 있는 API에 사용한다.
runtimeOnly런타임에 사용할 수 있지만 모듈을 컴파일하는 동안에는 표시되지 않는다. 

Dependency on the standard library

표준 라이브러리(stdlib)에 대한 의존성이 각 소스 세트(source set)에 자동으로 추가된다. 사용된 표준 라이브러리 버전은 코틀린 그레이들 플러그인 버전과 동일하다.

플랫폼-별 소스 세트의 경우, 라이브러리의 해당 플랫폼-별로 변형되며 나머지에는 공통 표준 라이브러리가 추가된다. 코틀린 그레이들 플러그인은 그레이들 빌드 스크립트의 compilerOptions.jvmTarget 컴파일러 옵션에 따라 적절한 JVM 표준 라이브러리를 선택한다.

표준 라이브러리 의존성을 명시적으로 선언하는 경우(예: 다른 버전이 필요한 경우), 코틀린 그레이들 플러그인은 이를 오버라이드(override)하거나 두 번째 표준 라이브러리를 추가하지 않는다.

표준 라이브러리가 전혀 필요하지 않은 경우, gradle.properties에 opt-out 옵션을 추가할 수 있다:

kotlin.stdlib.default.dependency=false

전이 의존성의 버전 정리

의존성에서 코틀린 버전 1.8.0 이상을 명시적으로 작성하는 경우(예: implementation(“org.jetbrains.kotlin:kotlin-stdlib:1.8.0”)), 코틀린 그레이들 플러그인은 kotlin-stdlib-jdk7 and kotlin-stdlib-jdk8 의존성을 위해 코틀린 버전을 변경하여 사용한다. 다른 stdlib 버전에서 클래스 중복을 방지하기 위한 것이다. kotlin-stdlib-jdk7kotlin-stdlib-jdk8kotlin-stdlib로 병합하는 방법에 대해 자세히 알아보자. kotlin.stdlib.jdk.variants.version.alignment 그레이들 프로퍼티를 사용하여 이 동작을 비활성화할 수 있다:

kotlin.stdlib.jdk.variants.version.alignment=false

버전을 정리하는 다른 방법

  • 버전 정리에 문제가 있는 경우, 코틀린 BOM을 통해 모든 버전을 정리한다. 빌드 스크립트에서 kotlin-bom에 대한 platform 의존성을 선언한다:

코틀린

implementation(platform("org.jetbrains.kotlin:kotlin-bom:1.9.0"))

그루비

implementation platform('org.jetbrains.kotlin:kotlin-bom:1.9.0')
  • 명시적인 표준 라이브러리가 없는 경우: gradle.propertieskotlin.stdlib.default.dependency=false가 있지만, 의존성 중 하나가 이전 코틀린 stdlib 버전(예: kotlin-stdlib-jdk7:1.7)을 전이적으로 가져오고 다른 의존성은 전이적으로 kotlin-stdlib:1.8+를 가져온다 - 이 경우, 전이 라이브러리의 1.9.0 버전이 필요할 수 있다.

코틀린

  dependencies {
    constraints {
      add("implementation", "org.jetbrains.kotlin:kotlin-stdlib-jdk7") {
        version {
          require("1.9.0")
        }
      }
      add("implementation", "org.jetbrains.kotlin:kotlin-stdlib-jdk8") {
        version {
          require("1.9.0")
        }
      }
    }
  }

그루비

  dependencies {
    constraints {
      add("implementation", "org.jetbrains.kotlin:kotlin-stdlib-jdk7") {
        version {
          require("1.9.0")
        }
      }
      add("implementation", "org.jetbrains.kotlin:kotlin-stdlib-jdk8") {
        version {
          require("1.9.0")
        }
      }
    }
  }
  • 코틀린 버전이 1.9.0인 경우: implementation("org.jetbrains.kotlin:kotlin-stdlib:1.9.0") 및 코틀린 그레이들 플러그인의 이전 버전(1.8.0 미만)은 – 코틀린 그레이들 플러그인을 업데이트한다.

코틀린

plugins {
    // `<...>`를 플러그인 명으로 교체
    kotlin("<...>") version "1.9.0"
}

그루비

plugins {
    // `<...>`를 플러그인 명으로 교체
    id "org.jetbrains.kotlin.<...>" version "1.9.0"
}

코틀린

dependencies {
    implementation("com.example:lib:1.0") {
        exclude(group = "org.jetbrains.kotlin", module = "kotlin-stdlib")
    }
}

그루비

dependencies {
    implementation("com.example:lib:1.0") {
        exclude group: "org.jetbrains.kotlin", module: "kotlin-stdlib"
    }
}

Set dependencies on test libraries

kotlin.test API는 지원되는 모든 플랫폼에서 코틀린 프로젝트를 테스트하는 데 사용할 수 있다. 그레이들 플러그인이 각 테스트 소스 세트(source set)에 해당하는 테스트 의존성을 유추할 수 있도록, kotlin-testcommonTest 소스 세트에 추가한다:

  • 공통 소스 세트에 대한 kotlin-test-commonkotlin-test-annotations-common
  • JVM 소스 세트용 kotlin-test-junit
  • Kotlin/JS 소스 세트용 kotlin-test-js

코틀린/네이티브 대상에는 추가 테스트 의존성이 필요하지 않으며, kotlin.test API 구현이 내장되어 있다:

코틀린

  kotlin {
    sourceSets {
      val commonTest by getting {
        dependencies {
          implementation(kotlin("test")) // 이것은 모든 플랫폼 의존성을 자동으로 가져온다.

        }
      }
    }
  }

그루비

  kotlin {
    sourceSets {
      commonTest {
        dependencies {
          implementation kotlin("test") // 이것은 모든 플랫폼 의존성을 자동으로 가져온다.
        }
      }
    }
  }

예를 들어, “org.jetbrains.kotlin:kotlin-test”의 경우, kotlin(“test”)과 같이 코틀린 모듈에 대한 의존성에 대한 줄임말를 사용할 수 있다.

공유 또는 플랫폼별 소스 세트에서도 kotlin-test 의존성을 사용할 수 있다.

코틀린/JVM의 경우 그레이들은 기본적으로 JUnit 4를 사용한다. 따라서, kotlin(“test”) 의존성은 JUnit 4의 변수인 kotlin-test-junit로 확인할 수 있다.

빌드 스크립트 테스트 태스크에서 useJUnitPlatform() 또는 useTestNG()를 호출하여 JUnit 5 또는 TestNG를 선택할 수 있다. 다음은 코틀린 멀티플랫폼 프로젝트에 대한 예시이다:

코틀린

  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()
  }

JVM에서 JUnit을 사용하여 코드를 테스트하는 방법을 알아보자.

다른 JVM 테스트 프레임워크를 사용해야 하는 경우, 프로젝트의 gradle.properties 파일에 kotlin.test.infer.jvm.variant=false 줄을 추가하여 자동 테스트 프레임워크 선택을 비활성화한다. 이 작업을 수행한 후, 프레임워크를 그레이들 의존성으로 추가한다.

빌드 스크립트에서 kotlin(“test”) 변수을 명시적으로 사용했고 프로젝트 빌드가 호환성 충돌로 작동을 멈춘 경우, 호환성 가이드에서 이 문제를 참고하자.

Set a dependency on a kotlinx library

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.7.1")
        }
      }
    }
  }

그루비

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

다중 플랫폼 라이브러리를 사용하고 공유 코드에 의존해야 하는 경우, 공유 소스 세트에서 의존성을 한 번만 설정한다. kotlinx-coroutines-core 또는 ktor-client-core와 같은 라이브러리의 기본 아티팩트 이름을 사용한다

코틀린

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

그루비

  kotlin {
    sourceSets {
      commonMain {
        dependencies {
          implementation 'org.jetbrains.kotlinx:kotlinx-coroutines-core:1.7.1'
        }
      }
    }
  }

Set dependencies at top level

대안으로, 구성 이름에 대해 패턴을 사용하여 최상위 수준에서 의존성을 지정할 수 있다. 이는 소스 세트의 의존성 DSL에서 사용할 수 없는 `gradleApi()`, `localGroovy()` 또는 `gradleTestKit()`와 같은 일부 그레이들 내장 의존성에 유용할 수 있다.

코틀린

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

그루비

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

What’s next?

다음 내용을 학습해보자: