[Gradle] 라이브러리 의존성 설정 종류
QueryDSL을 사용하기 위해서 gradle.build 파일에서 의존성 선언을 하던 도중 의문점이 생겼다.
dependencies 영역 안에 의존성을 추가하는데 annotationProcessor 는 처음보는 설정 이라서 어떤 건지 궁금증이 생겼다. 생각해보니 api, implementation 도 차이를 모른 채 별다른 생각 없이 사용했었다.
이제부터라도 정확한 목적을 가지고 사용하기 위해서 의존성 선언 옵션들에 대해 찾아보게 되었다.
우선 Gradle 공식 홈페이지에서 의존성 설정에 대해 찾아보았다.
가볍게 정리해보자면
api : 컴파일, 런타임 시 모두 필요하며 API 로 발행 시에도 포함되는 의존성
implementation : 컴파일, 런타임 시 모두 필요한 의존성
compileOnly : 컴파일 시에만 필요한 의존성 (런타임, api 발행 시 포함되지 않음)
compileOnlyApi : 컴파일 시에만 필요한 의존성 (api 발행 시 포함)
runtimeOnly : 런타임 시에만 필요한 의존성 (컴파일 클래스패스에 포함되지 않음)
testImplementation : 컴파일, 테스트 실행 시에 필요한 의존성
testCompileOnly : 테스트 컴파일 시에만 필요한 의존성
testRuntimeOnly : 테스트 실행 시에만 필요한 의존성
한눈에 알아보기 쉽게 표로 정리해보았다.
설정 이름 | 컴파일 시 필요 | 런타임 시 필요 | 의존성 전파 | 테스트에만 영향 |
api | O | O | O | X |
implementation | O | O | X | X |
compileOnly | O | X | X | X |
compileOnlyApi | O | X | O | X |
runtimeOnly | O | O | X | X |
annotationProcessor | O | X | X | X |
testImplementation | O | O | X | O |
testCompileOnly | O | X | X | O |
testRuntimeOnly | X | O | X | O |
API 발행 시에도 포함되는 의존성이 뭘까 싶어서 찾아보니 의존성 전파와 관련된 이야기였다. 예를 들어 A 모듈에 api로 추가한 의존성이 있다면 외부에서 A모듈을 사용할 때 해당 의존성에 접근할 수 있는 것이다.
다시 말하자면, B모듈에 C모듈을 api 로써 추가했다면 B모듈에 의존성을 갖고 있는 A모듈에서 C모듈을 직접적으로 접근하여 사용할 수 있다.
그러나 B 모듈에 C모듈을 implementation으로써 추가했다면 B모듈에 의존성을 갖고 있는 A모듈은 C모듈에 직접적으로 접근할 수 없다.
(추후 사진 추가)
이 외에도 runtimeClasspath, compileClasspath, apiElements, runtimeElements 와 같은 설정들이 존재하며 커스텀 설정도 가능하다고 한다.
그리고 검색 중에 찾게 되었는데, 아노테이션 처리가 필요한 라이브러리를 추가할 때는 annotationProcessor 를 사용할 수 있다
여담으로 QueryDsl 을 사용하기 위해 의존성을 다음과 같이 추가하였다.
SpringBoot 3버전 이상에서 QueryDsl 패키지는 다음과 같이 정의해야 한다고 한다.
dependencies {
api("com.querydsl:querydsl-jpa:${dependencyManagement.importedProperties['querydsl.version']}:jakarta")
annotationProcessor("com.querydsl:querydsl-apt:${dependencyManagement.importedProperties['querydsl.version']}:jakarta")
annotationProcessor("jakarta.annotation:jakarta.annotation-api")
annotationProcessor("jakarta.persistence:jakarta.persistence-api")
}
참고
7. Variant Aware Dependency Resolution
In Gradle, dependency resolution is often thought of from the standpoint of a consumer and a producer. The consumer declares dependencies and performs dependency resolution, while producers satisfy those dependencies by exposing variants. Gradle’s resolu
docs.gradle.org
Gradle의 라이브러리 의존성 옵션 정리
익숙함 문득 웹 프로젝트 관련 내용들을 정리해나가면서, gradle 파일을 보니까 다음과 같은 부분이 눈에 들어왔다. dependencies { implementation 'org.springframework.boot:spring-boot-starter-data-jpa' implementation 'or
twinparadox.tistory.com