Gradle의 여러가지 의존성 옵션

Spring Boot 프로젝트를 빌드할 때, Maven과 Gradle 중 하나의 빌드 툴을 정하여 사용하게 됩니다. 만약, Gradle이라는 빌드 툴을 사용할 경우, build.gradle이라는 파일이 생기게 됩니다. 해당 파일에서는 gradle 빌드 작업에 필요한 여러 가지 옵션, 설정, 동작 등을 정의해주며 의존성 라이브러리 또한 관리해줍니다. 

 

https://bloowhale.tistory.com/64

의존성을 관리해주는 dependency 프로퍼티는 굉장히 다양한 옵션을 가지고 있습니다. implementation, compileOnly, runtimeOnly,... 등. 일부 종속성은 소스 코드를 컴파일하는 데 사용되는 반면, 다른 종속성은 런타임에만 사용할 수 있어야 합니다. 이번 포스팅에서는 의존성 옵션들 각각의 특징에 대해 알아보겠습니다.

Java의 라이브러리 플러그인 구성

https://docs.gradle.org/7.4.2/userguide/java_library_plugin.html

1. api

해당 라이브러리를 수정하게 되면 본 모듈을 의존하는 모든 모듈들을 재빌드 합니다.

컴파일 타임과 런타임 시 사용자에게 의존성을 노출시킵니다. 

2. implementation 

내부적으로만 사용하고 사용자에게 의존성을 노출시키지 않습니다. 

해당 라이브러리를 수정하게 되면 본 모듈과 이 모듈을 직접 의존하고 있는 모듈만 재 빌드합니다.

3. compileOnly

compile 시에만 빌드하고, 빌드 결과물에는 포함하지 않습니다. 

runtime 시 필요 없는 라이브러리인 경우에 사용하는 것이 좋습니다. (runtime 환경에 이미 해당 라이브러리가 제공되고 있는 경우) 

4. runtimeOnly

runtime 시에만 필요한 라이브러리를 선언할 때 사용합니다. 

api vs. implementation

가장 많이 헷갈리는 부분이 api와 implementation인데, 이 두 개의 차이점을 예시를 들어 더 자세히 알아보려고 합니다. 

 

https://bluayer.com/13

A를 의존하는 모듈 B, B를 의존하는 모듈 C가 있다고 가정합시다. (A ← B ← C)
A가 api라면, C에서 A로 접근이 가능하며 A가 수정되면 B, C 모듈 역시 재 빌드됩니다.
A가 implementation이라면, C에서 A로 접근이 불가능하며 A 수정 시 C를 재 빌드하지 않습니다. 

그렇다면 api로 모든 의존성을 관리하면 되지 않을까?

물론 안됩니다. implementation만의 장점이 있기 때문입니다.

 

직접적으로 의존하는 모듈만 재 빌드하기 때문에 소요 시간이 api 옵션보다 더 적게 듭니다. 따라서 빌드 시간이 상당히 개선될 수 있습니다.

 

또한, api 옵션을 사용하면 연결된 모든 모듈의 api가 노출되기 때문에 사용자에게 필요 이상의 정보를 제공합니다. 그러나 implementation은 필요한 api만 노출하기 때문에 디자인 패턴의 주요 특징인 Transparency(투명성)을 잘 지킬 수 있습니다.