Gradle 8.0.2 Release Notes

8.0.1 나온지도 얼마 안됐는데...

thumb

 

이것은 Gradle 8.0의 두 번째 패치 릴리스입니다.

해결된 문제

  • #23698 Gradle 8 RC2에 메타 공간이 부족합니다.
  • #23962 명시적 툴체인이 없는 자바/스칼라 빌드: Gradle 8.0.1/Scala 2.13에서 빌드 실패
  • #23990 Gradle 8.0.+ JavaCompile에서 사용자 지정 컴파일러에 대한 지원을 자동으로 중단했습니다.
  • #24031 계측 변환기가 Gradle 8 및 7.6에서 다른 클래스 파일을 생성하여 원격 빌드 캐시 누락이 발생합니다.
  • #24109 이미 확인된 구성 확장이 더 이상 제대로 작동하지 않음
  • #24122 일부 플러그인의 구성 캐시 상태 업데이트
  • #24129 포함플러그인 관리사양에서 빌드 Gradle 8에서 디인큐베이션되었지만 문서는 여전히 인큐베이션 중이라고 말합니다.

첫 번째 패치 릴리스에서 해결된 문제:

  • #21551 도구 체인과 Scala 플러그인의 문서 통합 및 대상 플래그 문제
  • #23888 --새로운 사용 중단 주기 없이 그리고 사용 중단이 무효화되는 이유 없이 갑자기 재빌드 없음
  • #23905 Gradle 8.0이 문자열 클래스 오류에서 isBlank를 찾을 수 없는 스칼라 빌드 실패

사용자는 8.0 대신 2.8.0로 업그레이드하는 것이 좋습니다.

이 릴리스에서는 Kotlin DSL 빌드 스크립트를 컴파일하는 데 소요되는 시간을 줄이고 Kotlin DSL의 API 수준을 Kotlin 1.8로 업그레이드합니다.

첫 번째 호출에서 구성 캐시는 기존 병렬 모드에 비해 더 많은 작업을 병렬로 실행하여 빌드 속도를 높입니다.

또한 캐시 디렉터리의 보존 시간을 구성하여 Gradle 사용자 홈의 크기를 관리할 수 있습니다. 캐시 정리를 비활성화할 수도 있습니다.

Gradle 8.0에는 많은 버그 수정 및 기타 일반적인 개선 사항이 있습니다. 주 버전인 이 릴리스에는 더 이상 사용되지 않는 API 및 동작에 대한 변경 사항도 있습니다. 삭제된 API 및 동작에 대한 지침은 Gradle 7.x 업그레이드 가이드를 참조하세요.

목차

업그레이드 지침

래퍼를 업데이트하여 Gradle 8.0.2를 사용하도록 빌드를 전환합니다.

./gradlew 래퍼 --gradle-version=8.0.2

Gradle 7.x 업그레이드 가이드를 참조하여 지원 중단, 호환성이 손상되는 변경, Gradle 8.0.2로 업그레이드할 때의 기타 고려 사항에 대해 알아보세요.

Java, Groovy, Kotlin 및 Android 호환성에 대해서는 전체 호환성 노트를 참조하세요.

새로운 기능, 성능 및 유용성 개선

 

Kotlin DSL

Gradle의 Kotlin DSL은 지원되는 IDE에서 향상된 편집 환경(우수한 콘텐츠 지원, 리팩토링, 문서화 등)과 함께 Groovy DSL에 대한 대체 구문을 제공합니다.

더 빠른 Kotlin DSL 빌드 스크립트 컴파일

Gradle 8.0에는 전체 스크립트 컴파일 시간을 약 20% 단축하는 .gradle.kts 스크립트의 선언적 플러그인 {} 블록용 인터프리터가 도입되었습니다.

성능 향상은 일부 시나리오에서 제한됩니다. 인터프리터가 선언적 플러그인 {} 블록을 구문 분석할 수 없는 경우 Gradle은 Kotlin 컴파일러를 사용하도록 대체합니다. 다음과 같이 지원되는 형식만 사용해야 합니다.

plugins {
    id("java-library")                                // <1>
    id("com.acme.example") version "1.0" apply false  // <2>
    kotlin("jvm") version "1.7.21"                    // <3>
}
  1. 플러그인 식별자 문자열에 의해 요청된 플러그인
  2. 플러그인 식별자 및 버전 및/또는 플러그인 적용 플래그에 의해 요청된 플러그인
  3. kotlin으로 요청 된 플러그인 (...) 도우미

플러그인(예: alias(libs.plugins.acme)) 또는 유형이 안전한 플러그인 접근자(예: 'acme-plugin')에 버전 카탈로그 별칭을 사용하면 성능이 향상되지 않습니다. 이러한 형식에 대한 지원은 나중에 추가될 예정입니다.

플러그인 구문에 대한 자세한 내용은 선언적 plugins {} 블록 의 제한된 구문에 대한 문서를 참조하세요.

Kotlin DSL이 Kotlin API 레벨 1.8로 업데이트됨

이전에는 Kotlin DSL이 Kotlin API 레벨 1.4로 제한되었습니다. Gradle 8.0부터 Kotlin DSL은 Kotlin API 레벨 1.8로 고정됩니다. 이 변경으로 Kotlin 1.4.0 이후 Kotlin 언어 및 표준 라이브러리에서 Kotlin DSL 빌드 스크립트로 개선되었습니다.

이 업그레이드의 호환성이 손상되는 변경 및 호환성이 손상되지 않는 변경에 대한 자세한 내용은 7.x 업그레이드 가이드를 참조하세요.

Kotlin DSL은 새로운 자바 기능을 사용할 수 있습니다.

이전에는 .gradle.kts 스크립트 컴파일이 Java 8바이트 코드 및 기능으로 제한되었습니다. Gradle 8.0부터 Kotlin DSL은 빌드를 실행하는 JVM의 자바 버전을 사용합니다.

팀에서 Java 11을 사용하여 Gradle을 실행하는 경우 이제 빌드 스크립트에서 Java 11 라이브러리 및 언어 기능을 사용할 수 있습니다.

이것은 미리 컴파일 된 스크립트 플러그인에는 적용되지 않습니다 (아래 참조).

미리 컴파일된 스크립트 플러그인은 구성된 Java 툴체인을 사용합니다.

이전에는 미리 컴파일된 스크립트 플러그인 컴파일 에서 kotlinDslPluginOptions.jvmTarget에 의해 구성된 JVM 대상을 사용했습니다.

Gradle 8.0부터 사전 컴파일된 스크립트 플러그인은 프로젝트에 대해 구성된 Java 툴체인을 사용하거나 툴체인이 구성되지 않은 경우 Java 8을 사용합니다.

미리 컴파일된 스크립트 플러그인에 대해 Java 툴체인을 구성하는 방법에 대한 자세한 내용은 kotlin-dsl 플러그인 설명서를 참조하고, 변경된 동작에 대한 자세한 내용은 마이그레이션 가이드를 참조하세요.

 

buildSrc 빌드에 대한 개선 사항

이 릴리스에는 buildSrc 빌드가 포함된 빌드처럼 동작하도록 몇 가지 개선 사항이 포함되어 있습니다. 포함된 빌드는 증분 빌드 및 작업 캐싱을 더 잘 활용하기 위해 빌드 논리를 별도의 프로젝트 구성으로 구성하는 대체 방법입니다. 이제 그들은 동일한 혜택을 제공합니다.

buildSrc 작업을 직접 실행

이제 포함된 빌드의 작업에 사용된 것과 동일한 구문을 사용하여 명령줄에서 buildSrc 빌드의 작업을 실행할 수 있습니다. 예를 들어 gradle buildSrc:build를 사용하여 buildSrc 빌드에서 빌드 작업을 실행할 수 있습니다.

자세한 내용은 사용 설명서를 참조하십시오.

buildSrc는 다른 빌드를 포함 할 수 있습니다.

이제 buildSrc 빌드는 buildSrc/settings.gradle.kts 또는 buildSrc/settings.gradle에서 선언하여 다른 빌드를 포함할 수 있습니다. 이렇게 하면 buildSrc를 계속 사용하는 동안 빌드 논리를 더 잘 조직할 수 있습니다.

이 설정 스크립트에서 pluginsManagement { includeBuild(someDir) } 또는 includeBuild(someDir)를 사용하여 buildSrc에 다른 빌드를 포함할 수 있습니다.

자세한 내용은 사용 설명서를 참조하십시오.

buildSrc에 대한 테스트가 더 이상 자동으로 실행되지 않습니다.

Gradle은 buildSrc의 출력을 빌드할 때 해당 출력을 생성하는 작업만 실행합니다. 더 이상 빌드 작업을 실행하지 않습니다. 특히 이는 buildSrc 및 해당 하위 프로젝트의 테스트가 필요하지 않을 때 빌드 및 실행되지 않음을 의미합니다.

위에서 설명한 대로 다른 프로젝트와 동일한 방식으로 buildSrc에 대한 테스트를 실행할 수 있습니다.

초기화 스크립트가 buildSrc에 적용됩니다.

--init-script를 사용하여 명령줄에 지정된 초기화 스크립트는 이제 기본 빌드 및 포함된 모든 빌드 외에도 buildSrc에 적용됩니다.

자세한 내용은 사용 설명서를 참조하십시오.

 

구성 캐시

구성 캐시는 구성 단계의 결과를 캐시 하고 후속 빌드에 다시 사용하여 빌드 시간을 개선합니다. 이는 빌드 성능을 크게 향상시킬 수 있는 배양 기능입니다.

첫 번째 빌드에서 더 많은 병렬 처리

이제 구성 캐시를 사용하면 병렬 실행을 사용하도록 설정하는 것보다 더 세분화된 병렬 처리를 사용할 수 있습니다. Gradle 8.0부터 구성 캐시를 사용할 때 작업이 첫 번째 빌드와 병렬로 실행됩니다.

Gradle은 구성 캐시 항목을 재사용할 때 항상 작업을 병렬로 실행했습니다. 모든 작업은 기본적으로 병렬로 실행되며, 동일한 프로젝트 내의 작업에도 종속성 제약 조건이 적용됩니다. 이제 캐시 항목을 저장할 때도이 작업을 수행합니다.

구성 캐시가 사용 설정되고 Gradle이 현재 빌드와 호환되는 캐시 항목을 찾을 수 있으면 캐시에서 작업을 로드하고 격리하여 실행합니다. Gradle이 적절한 캐시 항목을 찾을 수 없는 경우 구성 단계를 실행하여 필요한 작업을 결정하고 새 캐시 항목에 저장한 다음 저장된 상태에 따라 즉시 빌드를 실행합니다.

이 새로운 동작에는 다음과 같은 몇 가지 이점이 있습니다.

  • 역직렬화 중에 발생하는 모든 문제는 캐시 누락 빌드에 보고되므로 더 쉽게 검색할 수 있습니다.
  • 작업은 캐시 누락 및 캐시 적중 횟수 빌드 모두에서 동일한 상태를 가지며 빌드 간의 일관성을 허용합니다.
  • Gradle은 캐시 누락 빌드에서 작업을 실행하기 전에 구성 상태에서 사용하는 메모리를 해제하여 최대 메모리 사용량을 줄일 수 있습니다.

캐시 누락과 캐시 적중 빌드 간의 이러한 일관된 동작은 첫 번째(캐시 누락) 빌드에서 더 많은 문제를 발견할 수 있으므로 구성 캐시 사용으로 전환하는 사용자에게 도움이 됩니다.

자세한 내용은 사용 설명서를 참조하십시오.

핵심 플러그인과의 확장된 호환성

gradle init 명령은 구성 캐시가 활성화된 상태에서 사용할 수 있습니다.

ANTLR 플러그인 및 Groovy DSL 미리 컴파일된 스크립트는 이제 구성 캐시와 호환됩니다.

모든 핵심 Gradle 플러그인에 대한 구성 캐시 지원의 현재 상태는 구성 캐시 문서에서 확인할 수 있습니다.

 

자바 툴체인 개선 사항

업데이트된 툴체인 다운로드 저장소

Gradle 7.6에서는 유연성 향상을 위해 툴체인 리포지토리가 도입 되었습니다 . Gradle 8.0에는 더 이상 기본 툴체인 프로비저너가 없습니다. 하나 이상의 Java 도구 체인 저장소를 명시적으로 선언해야 합니다. 이것은 Foojay 툴체인 플러그인과 같은 툴체인 저장소 플러그인을 통해 수행 할 수 있습니다. 

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

자세한 내용은 사용 설명서를 참조하십시오.

 

일반적인 개선 사항

 

구성 가능한 Gradle 사용자 홈 캐시 정리 및 보존

이전에는 Gradle 사용자 홈의 캐시 정리에 고정 보관 기간(캐시에 따라 30일 또는 7일)이 사용되었습니다. 이제 Gradle 사용자 홈의 초기화 스크립트에 있는 설정 개체를 통해 이러한 보관 기간을 구성할 수 있습니다.

beforeSettings { settings ->
    settings.caches {
        downloadedResources.removeUnusedEntriesAfterDays = 45
    }
}

또한 이전에는 Gradle 사용자 홈의 org.gradle.cache.cleanup Gradle 속성을 통해서만 캐시 정리를 부분적으로 사용 중지할 수 있었습니다. 캐시 정리를 사용 중지하면 이제 Gradle 사용자 홈에서 더 많은 캐시에 영향을 미치며 Gradle 사용자 홈의 초기화 스크립트에 있는 설정 개체를 통해 구성할 수도 있습니다.

자세한 내용은 사용 설명서를 참조하십시오.

향상된 경고 모드 모두 및 실패가 이제 더 자세하게 표시됩니다.

Gradle 8.0 이전에는 모든 경고를 인쇄해야 하는 경고 모드가 각 특정 경고 메시지에 대해 하나만 인쇄되었습니다. 이로 인해 일부 경고 메시지가 누락되었습니다. 예를 들어 동일한 메시지가 포함된 두 개의 경고가 있지만 빌드 프로세스의 다른 단계(즉, 다른 스택 추적)에서 발생한 경우 하나만 인쇄되었습니다.

이제 메시지와 스택 추적의 각 조합에 대해 하나씩 인쇄됩니다. 이 결과는 더 장황하지만 더 완벽합니다.

자세한 내용은 사용 설명서를 참조하십시오.

종속성 확인 메타데이터는 신뢰 이유 문서화를 지원합니다.

종속성 확인 메타데이터는 사용 중인 종속성이 해당 종속성의 체크섬과 일치하도록 하여 프로젝트를 안전하게 유지하는 데 도움이 됩니다. 이 메타데이터는 XML 구성 파일에 있으며 이제 reason 특성을 허용합니다. 이 reason 속성을 사용하면 아티팩트를 신뢰할 수 있는 이유 또는 확인 메타데이터.xml에서 직접 아티팩트에 대해 선택한 체크섬 확인이 필요한 이유에 대한 자세한 정보를 확인할 수 있습니다.

종속성 확인 메타데이터 파일 확인-메타데이터가 있는 다음 노드.xml 이제 reason 속성을 지원합니다.

  • 신뢰할 수 있는 아티팩트 아래의 신뢰 XML 노드
  • 구성 요소 아래의 MD5, SHA1, SHA256 및 SHA512 노드

아티팩트를 신뢰할 수 있는 이유 또는 선택한 체크섬 확인이 확인 메타데이터.xml에서 직접 아티팩트에 필요한 이유에 대한 자세한 정보를 제공하는 데 도움이 됩니다.

자세한 내용은 사용 설명서를 참조하십시오.

신뢰할 수 있는 키 링 파일은 CLI에서 쉽게 내보낼 수 있습니다.

CI 빌드가 키 서버와 통신해야 하는 횟수를 최소화하기 위해 Gradle은 로컬 키링 파일을 지원합니다. 이 파일은 정확성을 유지하기 위해 자주 내보내야 합니다. 더 이상 신뢰할 수 있는 키를 내보낼 때 전체 확인 메타데이터를 작성할 필요가 없습니다.

이제 export-keys 플래그를 사용하여 이미 신뢰할 수 있는 모든 키를 내보낼 수 있습니다.

./gradlew --export-keys

자세한 내용은 사용 설명서를 참조하십시오.

중첩된 복합 빌드는 더 많은 경우에 작동합니다.

특히 더 큰 프로젝트를 구조화하기 위해 buildSrc 대신 포함된 빌드 논리 빌드를 사용하는 것이 일반적입니다. 이제 빌드 논리를 사용하는 여러 프로젝트를 포함하는 복합 빌드를 가질 수 있습니다.

예를 들어 다음 설정을 수행합니다.

.
├── rootBuild
│   ├── settings.gradle.kts
│   └── build-logic
│       └── settings.gradle
└── included-build
    ├── settings.gradle.kts
    └── build-logic
        └── settings.gradle.kts

// rootBuild/settings.gradle
includeBuild("build-logic")
includeBuild("../included-build")

// included-build/settings.gradle
includeBuild("build-logic")

Gradle 8 이전에는 :build-logic의 경로 충돌로 인해 이 빌드가 실패했습니다. 이제 디렉터리 계층 구조가 중첩된 포함된 빌드에 경로를 할당하는 데 사용되므로 작동합니다. 예를 들어 다음을 사용하여 다른 빌드 로직 빌드에서 작업을 실행할 수 있습니다.

./gradlew :build-logic:test
./gradlew :included-build:build-logic:test

자세한 내용은 복합 빌드 및 빌드 논리에 대한 사용자 설명서를 참조하세요. 업그레이드 가이드를 방문하여 포함된 빌드에 대한 빌드 경로의 변경 내용에 대해 알아보세요.

 

코드 품질 플러그인 개선

CodeNarc 플러그인이 Groovy 런타임 버전을 감지합니다.

CodeNarc는 그루비 프로젝트에 대한 정적 분석을 수행합니다. 이제 Groovy 4와 함께 사용할 별도의 버전을 게시합니다. Gradle은 현재 Groovy 3와 함께 제공됩니다.

향후 호환성을 보장하기 위해 CodeNarc 플러그인은 이제 현재 Groovy 런타임에 적합한 CodeNarc 버전을 자동으로 감지합니다.

CodeNarcExtension의 toolVersion 속성을 사용하여 CodeNarc 버전을 명시적으로 지정할 수 있습니다.

기본적으로 병렬 실행으로 더 빠른 PMD 분석

PMD 플러그인은 정적 코드 분석기를 사용하여 프로젝트의 Java 소스 파일에 대한 품질 검사를 수행합니다. 이제 Gradle 작업자 API 및 JVM 도구 체인을 사용합니다. 이 도구는 이제 외부 작업자 프로세스를 통해 분석을 수행하므로 해당 작업을 이제 한 프로젝트 내에서 병렬로 실행할 수 있습니다.

Java 프로젝트에서 이 도구는 프로젝트에 필요한 것과 동일한 버전의 Java를 사용합니다. 다른 유형의 프로젝트에서는 Gradle 데몬에서 사용하는 것과 동일한 버전의 Java를 사용합니다.

자세한 내용은 사용 설명서를 참조하십시오.

프로모션 기능은 이전 버전의 Gradle에서 인큐베이팅되었지만 이제는 지원되며 이전 버전과의 호환성이 적용되는 기능입니다. 자세한 내용은 "기능 수명 주기"의 사용자 설명서 섹션을 참조하십시오.

다음은 이 Gradle 릴리스에서 홍보된 기능입니다.

GradleConnector.disconnect() 메서드는 이제 안정적인 것으로 간주됩니다.

AntlrSourceDirectorySet 인터페이스는 이제 안정적인 것으로 간주됩니다.

Ear.getAppDirectory() 메서드는 이제 안정적인 것으로 간주됩니다.

EclipseClasspath.getContainsTestFixture() 메서드는 이제 안정적인 것으로 간주됩니다.

다음 유형 및 메서드는 이제 안정적인 것으로 간주됩니다.

  • GroovySourceDirectorySet
  • GroovyCompileOptions.getDisabledGlobalASTTransformations()

인터페이스는 이제 안정적인 것으로 간주됩니다.

War.getWebAppDirectory() 메서드는 이제 안정적인 것으로 간주됩니다.

Settings.pluginManagement의 includeBuild 메서드는 이제 안정적입니다. 빌드 논리에 기여하는 빌드를 포함하는 권장 방법입니다.

Settings.dependencyResolutionManagement(Action) 및 Settings.getDependencyResolutionManagement() 메서드는 이제 안정적인 것으로 간주됩니다.

종속성 확인 관리의 모든 메서드는 이제 중앙 리포지토리 선언을 위한 메서드를 제외하고 안정적입니다.

해결된 문제

Gradle 7.8.0에서 2 가지 문제가 수정되었습니다.

  • [#24129] - 플러그인 관리 사양의 빌드 포함Gradle 8에서 배양 해제되었지만 문서는 여전히 배양 중이라고 말합니다.
  • [#24122] - 일부 플러그인에 대한 구성 캐시 상태 업데이트
  • [#24109] - 이미 해결된 구성 확장이 더 이상 제대로 작동하지 않음
  • [#24031] - InstrumentingTransformer는 Gradle 8 및 7.6에서 다른 클래스 파일을 생성하여 원격 빌드 캐시 누락으로 이어집니다.
  • [#23990] - Gradle 8.0.+ 'JavaCompile'에서 사용자 정의 컴파일러에 대한 지원을 자동으로 중단했습니다.
  • [#23962] - 명시 적 툴체인이없는 자바 / 스칼라 빌드 : Gradle 8.0.1 / Scala 2.13에서 빌드 실패
  • [#23698] - Gradle 8 RC2는 메타 공간이 부족합니다.

알려진 문제

알려진 문제는 이 릴리스의 변경 사항과 직접 관련된 릴리스 이후에 발견된 문제입니다.

현재 Gradle 8.0.2의 알려진 문제는 없습니다.

 

 

 

 

728x90
반응형

티스토리툴바