제5조: 공유된 libs.versions.toml의 모험

Sommaire

소개
1. 버전 카탈로그 (libs.versions.toml) : 한 가지 알림
2. 문제: 컴포지트 빌드와 두 개의 별개의 세계
3. 솔루션 : 의존성 해결 공유
4. 결론: 잘 관리된 컴포지트 빌드의 힘

소개

대상 독자 : 멀티빌드 프로젝트에서 의존성을 관리하고 있는 Gradle 개발자

우리의 플러그인을 만들기 위한 탐색에서`site-baker`우리는 깨끗하고 중앙집중된 코드베이스를 유지하려고 노력했습니다. 현대 Gradle 생태계에서 최고의 실천 방법 중 하나는 이를 사용하는 것입니다.버전 카탈로그(libs.versions.toml) 로 의존성을 관리합니다. 하지만 프로젝트가 더 복잡해질 때 무슨 일이 일어나나요, 예를 들어 하나의복합재 구축독립적인 빌드(우리의 플러그인)를 다른 곳에 포함해야 하는 곳은 어디인가요?

여기서 우리 모험은 예상치 못한 방향으로 바뀌었다. 우리는 우리 플러그인이`site-baker`, 그것은 자체적으로 Gradle 프로젝트인, 우리 주요 프로젝트와 동일한 버전 카탈로그를 사용한다. 이 글은, 우리 시리즈의 다섯 번째이며, 우리가 이 도전을 어떻게 해결했는지 설명한다.

1. 버전 카탈로그 (`libs.versions.toml`) : 한 가지 알림

파일`gradle/libs.versions.toml`Gradle의 기능으로, 프로젝트의 의존성 버전과 좌표를 중앙 집중화할 수 있습니다. 일반적으로 네 개의 섹션으로 구성됩니다 :

[versions]: 버전 번호에 대한 별칭을 정의합니다(예:`kotlin = "1.9.20"`).
[libraries]: 완전한 종속성에 대한 별칭을 정의하며, 위에 정의된 버전을 사용합니다(예:`kotlin-stdlib = { module = "org.jetbrains.kotlin:kotlin-stdlib", version.ref = "kotlin" }`).
[bundles]: 여러 라이브러리를 하나의 별칭으로 묶습니다 (ex:`jackson = ["jackson-core", "jackson-databind"]`).
[plugins]: Gradle 플러그인에 대한 별칭을 정의합니다.

정의되면 Gradle은 자동으로 타입이 지정된 액세서를 생성하며, 이로 인해 귀하의`build.gradle.kts`훨씬 더 읽기 쉽습니다:

dependencies {
    // Au lieu de : implementation("org.jetbrains.kotlin:kotlin-stdlib:1.9.20")
    implementation(libs.kotlin.stdlib)
}

버전 카탈로그의 데이터 흐름

@startuml
!theme plain
file "gradle/libs.versions.toml" as Toml
node "Gradle" as G
file "build.gradle.kts" as BuildScript

Toml --> G : "읽히기"
G --> BuildScript : "접근자를 생성합니다 `libs"
BuildScript -> G : "사용해 `libs` 로 종속성을 선언해"
@enduml

2. 문제: 컴포지트 빌드와 두 개의 별개의 세계

우리 프로젝트 구조는 하나의복합체 구축. 주요 프로젝트 (thymeleaf.cheroliv.com) 플러그인 프로젝트를 포함합니다 (site-baker) 명령을 통해`includeBuild("site-baker")파일에서`settings.gradle.kts.

복합 빌드 구조

@startuml
!theme plain
package "주요 프로젝트" {
  file "settings.gradle.kts" as MainSettings
  folder "그레이들" {
    file "libs.versions.toml" as MainToml
  }
}

package "플러그인 `site-baker` (포함된 빌드)" {
  file "settings.gradle.kts" as PluginSettings
  file "build.gradle.kts" as PluginBuild
}

MainSettings -> PluginSettings : `includeBuild("사이트 베이커")`
PluginBuild ..> MainToml : **Voulait accéder à...**
note right on link: ...mais ne pouvait pas !
@enduml

문제는 기본적으로 포함된 빌드가 하나이다별개의 세계. 그의 고유한 구성과 고유한 생명 주기를 가지고 있으며, 파일을 보지 못한다`libs.versions.toml`주요 빌드. 우리`plugin/build.gradle.kts`사용하려고 노력하고 있었다`libs.plugins.kotlin.jvm`, 그러나 그 객체`libs`올바른 TOML 파일에서 생성되지 않아서 빌드 오류가 발생했습니다.

3. 솔루션 : 의존성 해결 공유

여러 차례의 연구 끝에, 해결책이 이 경우를 정확히 위해 설계된 Gradle 기능임이 밝혀졌습니다:`dependencyResolutionManagement`.

파일에`settings.gradle.kts` du 포괄적인 빌드 (site-baker/settings.gradle.kts), 우리는 Gradle에게 사용할 버전 카탈로그를 어디서 찾을 수 있는지 알려줄 수 있습니다.

다음은 우리가 추가한 구성`site-baker/settings.gradle.kts`:

// site-baker/settings.gradle.kts

dependencyResolutionManagement {
    repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
    repositories {
        gradlePluginPortal()
        mavenCentral()
    }
    versionCatalogs {
        create("libs") {
            from(files("../gradle/libs.versions.toml"))
        }
    }
}

rootProject.name = "site-baker"
include("plugin")

핵심 부분을 분석해 봅시다:

versionCatalogs {
    create("libs") { // Crée un catalogue nommé 'libs'
        from(files("../gradle/libs.versions.toml")) // En utilisant ce fichier
    }
}

create("libs")`우리는 별칭을 통해 접근 가능한 버전 카탈로그를 선언합니다`libs.
from(files("../gradle/libs.versions.toml")): 이것은 마법입니다. 우리는 Gradle에게 이 카탈로그의 소스가 디렉터리에 위치한 TOML 파일이라고 나타냅니다.gradle du 상위 프로젝트(

(Note: The output includes a leading space and an opening parenthesis as in the source, with no additional text.)../)

이 구성으로 빌드`site-baker`이제 그는 메인 프로젝트의 버전 카탈로그를 사용해야 한다는 것을 알고 있습니다. 객체`libs`정상적으로 생성되며, 종속성이 예상대로 해결됩니다.

4. 결론: 잘 관리된 컴포지트 빌드의 힘

이 경험은 많은 교훈을 제공했습니다. 버전 카탈로그는 유지보수성을 위한 훌륭한 도구이지만, 복합 빌드 시나리오에서의 동작은 항상 직관적이지 않습니다.

핵심은 포함된 빌드가 여전히 독립된 빌드라는 사실을 기억하는 것입니다. 버전 카탈로그와 같은 구성 설정을 공유하려면 Gradle이 제공하는 명시적인 메커니즘, 예를 들어 블록을 사용해야 합니다.dependencyResolutionManagement`안에`settings.gradle.kts.

이 문제를 해결함으로써 우리는 단순히 빌드를 더 깨끗하게 만들었을 뿐만 아니라, 플러그인과 메인 프로젝트가 의존성에 대한 단일 진실의 출처를 공유하도록 함으로써 프로젝트의 일관성도 강화했습니다.

다음 기사에서는 의존성 관리가 강력하고 중앙 집중화되었으므로 이제 더 복잡한 작업을 추가하여 플러그인을 계속 풍부하게 할 것입니다.

소개

1. 버전 카탈로그 (libs.versions.toml) : 한 가지 알림

2. 문제: 컴포지트 빌드와 두 개의 별개의 세계

3. 솔루션 : 의존성 해결 공유

4. 결론: 잘 관리된 컴포지트 빌드의 힘

관련 기사

1. 버전 카탈로그 (`libs.versions.toml`) : 한 가지 알림