일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 |
- JPA
- 플러그인 로컬 테스트
- 스트림
- intellij 플러그인 개발
- 컬럼명중복
- Flush
- hibernate 쿼리실행 순서
- Java
- dto매핑우선순위
- 오라클쿼리테스트사이트
- IntelliJ
- 로컬에서 플러그인 추가
- plugin local
- 쿼리테스트사이트
- Stream
- error 2002 (hy000): can't connect to local mysql server through socket '/tmp/mysql.sock' (2)
- java 로 intellij 플러그인
- port&adapter architecture
- 자바
- Oracle
- group by group by rollup 차이
- Kafka
- 포트앤어댑터 아키텍처
- 쓰기지연sql저장소 쿼리실행순서
- 쿼리실행순서
- 중복컬럼dto매핑
- sql 테스트 사이트
- 쓰기지연저장소
- ls -lgaf
- intellij 플러그인 만들기
- Today
- Total
개린이 탈출기
[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
'개발 조각 지식' 카테고리의 다른 글
EAI 간단 개요 (0) | 2025.03.12 |
---|---|
Apache Kafka, Spring Kakfa, Spring Cloud Stream 의 차이점 (0) | 2025.03.12 |
[IntelliJ] 빌드 오류 해결.(Language level 변경) (0) | 2024.11.20 |
[k8s]@Value 를 통한 baseUrl 값 설정 (1) | 2024.11.11 |
ci/cid pipeline와 관련된 조각 정보 (1) | 2024.11.07 |