Version Catalog 도입을 위한 온보딩
gradle 버전 관리를 위한 Version Catalog 도입
안녕하세요. 서비스 개발팀 Android 개발자 두루라고 합니다.
최근 프로젝트에 도입하려고 하는 gradle 버전 관리를 위한 Version Catalog 온보딩 내용에 대해서 이야기를 해보려고 합니다.
Why 버전 관리?
하나의 프로젝트에서 여러 개의 모듈을 사용하는 경우, 사용해야 할 라이브러리가 추가될수록 build.gradle 관리가 점점 어려워지게 됩니다.
또한 새로운 프로젝트를 생성할 때마다 매번 build.gradle 파일들을 새로 작성해줘야 하는 번거로움도 존재합니다.
우선 Version Catalog를 살펴보기 전에 build.gradle에 대해서 먼저 살펴보도록 하겠습니다.
build.gradle
build.gradl은 파일 자체가 Project 객체로, Project 객체는 Project 인터페이스를 구현하는 구현체이며,
Project 객체는 프로젝트 단위에서 필요한 작업을 수행하기 위한 모든 메서드와 프로퍼티를 모아놓은 객체입니다.
이렇게 build.gradle에 작성하는 수많은 코드들은 모두 Project 객체의 프로퍼티와 메서드가 되며, Project 객체는 프로젝트 이름부터, 변수, 메서드를 모두 포함하는 객체가 됩니다.
Project 객체는 내부적으로 수많은 메서드, 프로퍼티를 가지고 있으며, 대표적으로 java application용 build.gradle이 가진 plugins, repositores, dependencies, application 메서드들이 있습니다.
Gradle Task를 이용해 java application을 빌드하게 되면 build task는 이 메서드들을 수행시키게 됩니다.
Version Catalog
프로젝트를 진행하다 보면 gradle에서의 라이브러리 및 플러그인의 의존성 관련해서 관리를 위하여 ext, buildSrc 등 여러 가지 방법들이 있었습니다.
gradle 버전이 7.0으로 업데이트되면서 Version Catalog라는 새로운 버전 관리 방법이 등장을 하였습니다.
그렇다면 이제 Version Catalog는 어떤 장점이 있어서 사용을 하는지에 대해서 살펴보도록 하겠습니다.
Version Catalog 장점
하나의 파일로 여러 프로젝트 또는 모듈의 버전 관리를 통합할 수 있습니다.
함께 사용되는 의존성들에 대해서 bundle로 묶어서 선언하여 관리가 가능해집니다.
IDE 상에서 각각의 Catalog 별로 자동 완성을 지원하는 등의 여러 가지 편리성을 제공하므로 개발적으로 편리하게 됩니다.
본인이 지정한 변수명으로 정의를 할 수 있으므로 가독성 측면에서도 좋습니다.
(물론 위의 가독성 측면에서의 장점이 극대화되기 위해선 정의한 변수명들에 대한 명세서가 있으면 가독성 측면에서의 장점을 극대화시킬 수 있다는 생각이 듭니다.)
Version Catalog 적용
위에서 말한 장점들을 실제로 적용을 하면서 보도록 하겠습니다.
적용을 하기 전 Version Catalog를 활용하여 gradle의 변화에 대해서 먼저 살펴보도록 하겠습니다.
위에서의 코드로 볼 수 있듯 기존의 gradle에 있던 수많은 라이브러리 의존성 관련된 코드를 plugins 단 한 줄로도 요약이 가능하게 되며 라이브러리 의존성에 대해서 Kotlin 클래스 하나로 통합하여 관리가 가능해집니다.
1. Gralde Settings
Version Catalog는 gradle 7.4 버전부터 정식으로 지원을 하므로, 이전 버전의 경우에는 수동으로 toml 파일을 찾아서 지정을 해줘야 합니다.
2. toml 파일 생성 (gradle/didalibs.versions.toml)
toml 파일 생성을 하며, 파일 생성 위치는 gradle/didalibs.versions.toml입니다.
위의 toml 파일을 살펴보면 versions, libraries, bundles라는 키워드들을 살펴볼 수 있습니다.
- versions : 라이브러리 버전에 대한 명시입니다.
- libraries : 각각의 라이브러리 의존성에 대한 명시입니다.
- bundles : 라이브러리를 묶어서 한 번에 선언이 가능하도록 하는 명시입니다.
3. 프로젝트 에서의 적용
build.gradle.kts에서의 수정
위의 적용이 완료된 것을 살펴보면 version에 대해서는 통합하여 관리를 할 수 있지만 여전히 gradle에서 라이브러리 의존성에 대해서 정의를 해야 한다는 것이 보이게 됩니다.
그렇다면 이제부터 처음에 봤던 plugins 한 줄로 의존성에 대해서 관리하는 것에 대해서 살펴보도록 하겠습니다.
1. build-logic 모듈 생성 & build-logic에 관련된 settings.gradle 생성
2. 사용할 라이브러리 및 Android 기본 세팅에 대한 정의
KotlinAndroid.kt (Android의 기본 Setting을 관리하는 파일입니다.)
AndroidApplicationConventionPlugin.kt (실질적으로 aab, apk파일로 추출이 되는 app 모듈에 대한 정의 파일입니다.)
AndroidDataConventionPlugin.kt (Data 모듈에 대해서 사용하는 의존성에 대한 정의 파일입니다.)
AndroidHiltConventionPlugin.kt (현재 프로젝트에서 Hilt를 사용하므로 Hilt에 대한 의존성 정의 파일입니다.)
AndroidLibraryConventionPlugin.kt (Android Module로 생성한 모듈에 대해서 기본적으로 가지고 있어야 하는 세팅에 대해서 정의를 하는 파일입니다.)
AndroidPresentationConventionPlugin.kt (Presentation 모듈에 대해서 사용하는 의존성에 대한 정의 파일입니다.)
3. 이제 위에서 정의한 AndroidXXXConventionPlugin에 대해서 실질적으로 gradle에서 적용을 할 수 있도록 plugin으로 등록을 하도록 하겠습니다.
위의 방법으로 하면 처음 Version Catalog 적용 전과 후에서의 이미지에서 본 것처럼 plugin 한 줄로 해당 모듈에 대해서 gradle의 의존성에 대해서 관리가 가능해집니다.
이상으로 gradle 버전 관리를 위한 version catalog 온보딩 도입에 대해서 살펴보았습니다.
글을 마치며
gradle의 버전 관리를 위해서 version catalog 온보딩을 적용하면서 plugins를 통해서 기존 gradle에 있던 수많은 라이브러리 및 세팅에 대한 의존성의 코드들이 줄어든 것을 살펴볼 수 있었으며,
여러 모듈들에서 gradle버전 관리 및 라이브러리 의존성 추가 시 일일이 하며 발생했던 빌드 에러등에 대한 문제들도 한 번에 해결을 할 수 있었습니다.
추가적인 내용
현재 version catalog 도입을 위하여 now in android를 참고하였으며,
now in android에서는 하나의 프로젝트가 아닌 여러 프로젝트에서 동일한 세팅 및 관리를 위하여
build-logic프로젝트를 만들어 import를 시키는 방법으로 작성이 된 것을 확인할 수 있었습니다.
현재 저희의 프로젝트에서는 모듈로 생성을 하여 settings.gradle.kts를 생성하여 작업을 하였지만,
여러 프로젝트에서의 관리를 위해서 build-logic을 생성한다면, build-logic 프로젝트를 생성 후 사용할 각각의 프로젝트에서 사용을 하는 방법으로 장점을 극대화할 수 있다는 생각이 들었습니다.
글 작성 이후 gradle 8.0 RC-1 버전이 나오면서, version catalog 쓰시는 분들 참고하실만한 내용이 있어서 공유드립니다.
새로운 버전의 장점을 사용하려면 alias를 지워 사용을 하여야 한다는 내용들입니다.
참고 링크 : https://github.com/gradle/gradle/releases/tag/v8.0.0-RC1 (gradle 8.0 RC-1 관련)
