1. 개요
이 사용방법(예제)에서는 Gradle 빌드 스크립트에서 의존성을 선언하는 방법을 살펴보겠습니다. 우리의 예에서는 Gradle 6.7을 사용할 것 입니다.
2. 일반적인 구조
Java 프로젝트를 위한 간단한 Gradle 스크립트부터 시작하겠습니다 .
plugins {
id 'java'
}
repositories {
mavenCentral()
}
dependencies {
implementation 'org.springframework.boot:spring-boot-starter:2.3.4.RELEASE'
testImplementation 'org.springframework.boot:spring-boot-starter-test:2.3.4.RELEASE'
}위에서 볼 수 있듯이 플러그인 , 리포지토리 및 의존성의 세 가지 코드 블록이 있습니다 .
먼저 plugins 블록은 이것이 Java 프로젝트임을 알려줍니다. 두 번째로, 의존성 블록은 버전 2.3.4를 선언합니다 . 프로젝트의 프로덕션 소스 코드를 컴파일하는 데 필요한 spring-boot-starter 의존성 의 릴리스 . 또한 프로젝트의 테스트 스위트가 컴파일 하려면 spring-boot-starter-test 가 필요하다고 명시되어 있습니다.
Gradle 빌드는 리포지토리 블록에 정의된 대로 Maven Central 리포지토리에서 모든 의존성을 가져옵니다 .
의존성을 정의하는 방법에 집중합시다.
3. 의존성 구성
의존성을 선언할 수 있는 다양한 구성이 있습니다. 이와 관련하여 우리는 나중에 살펴보겠지만 어느 정도 정확하도록 선택할 수 있습니다.
3.1. 의존성을 선언하는 방법
시작하려면 구성에 4가지 부분이 있습니다.
- 그룹 – 조직, 회사 또는 프로젝트의 식별자
- 이름 – 의존성 식별자
- 버전 – 가져오려는 버전
- 분류자 – 동일한 그룹 , 이름 및 버전의 의존성을 구별하는 데 유용합니다.
두 가지 형식으로 의존성을 선언할 수 있습니다. 계약 형식을 사용하면 의존성을 String 으로 선언할 수 있습니다 .
implementation 'org.springframework.boot:spring-boot-starter:2.3.4.RELEASE'
대신 확장 형식을 사용하여 Map 으로 작성할 수 있습니다 .
implementation group:'org.springframework.boot', name: 'spring-boot-starter', version: '2.3.4.RELEASE'
3.2. 구성 유형
또한 Gradle은 다양한 의존성 구성 유형을 제공합니다.
- api – 의존성을 명시적으로 만들고 클래스 경로에 노출하는 데 사용됩니다. 예를 들어, 라이브러리 소비자에게 투명하게 라이브러리를 구현할 때
- 구현 – 프로덕션 소스 코드를 컴파일하는 데 필요하며 순전히 내부적입니다. 패키지 외부에 노출되지 않습니다.
- compileOnly – 소스 전용 어노테이션 또는 어노테이션 프로세서와 같이 컴파일 시간에만 선언해야 할 때 사용됩니다. 런타임 클래스 경로 또는 테스트 클래스 경로에 나타나지 않습니다.
- compileOnlyApi – 컴파일 시간에 필요할 때와 소비자를 위한 클래스 경로에서 볼 수 있어야 할 때 사용
- runtimeOnly – 런타임에만 필요하고 컴파일 시간에는 사용할 수 없는 의존성을 선언하는 데 사용됩니다.
- testImplementation – 테스트를 컴파일하는 데 필요
- testCompileOnly – 테스트 컴파일 시간에만 필요
- testRuntimeOnly – 테스트 런타임에만 필요
최신 버전의 Gradle은 compile , testCompile , runtime 및 testRuntime 과 같은 일부 구성을 더 이상 사용하지 않습니다 . 글을 쓰는 시점에서 그들은 여전히 사용 가능합니다.
4. 외부 의존성의 유형
Gradle 빌드 스크립트에서 발생하는 외부 의존성의 유형을 살펴보겠습니다.
4.1. 모듈 의존성
기본적으로 의존성을 선언하는 가장 일반적인 방법은 저장소를 참조하는 것입니다. Gradle 저장소는 그룹 , 이름 및 버전 별로 구성된 모듈 모음입니다 .
사실 Gradle은 리포지토리 블록 내부의 지정된 리포지토리에서 의존성을 풀다운합니다 .
repositories {
mavenCentral()
}
dependencies {
implementation 'org.springframework.boot:spring-boot-starter:2.3.4.RELEASE'
}4.2. 파일 의존성
프로젝트가 항상 자동화된 의존성 관리를 사용하는 것은 아니기 때문에 일부 프로젝트는 의존성을 소스 코드 또는 로컬 파일 시스템의 일부로 구성합니다. 따라서 의존성이 있는 정확한 위치를 지정해야 합니다.
이를 위해 파일 을 사용 하여 의존성 컬렉션을 포함 할 수 있습니다 .
dependencies {
runtimeOnly files('libs/lib1.jar', 'libs/lib2.jar')
}마찬가지로, 우리가 사용할 수있는 filetree을 의 계층 구조 포함 항아리의 디렉토리에있는 파일을 :
dependencies {
runtimeOnly fileTree('libs') { include '*.jar' }
}4.3. 프로젝트 의존성
한 프로젝트는 코드를 재사용하기 위해 다른 프로젝트에 의존할 수 있으므로 Gradle은 그렇게 할 수 있는 기회를 제공합니다.
우리 프로젝트가 공유 프로젝트 에 의존한다고 선언하고 싶다고 가정해 봅시다 :
dependencies {
implementation project(':shared')
}4.4. Gradle 의존성
작업 또는 플러그인 개발과 같은 특정 경우에는 사용 중인 Gradle 버전에 속하는 의존성을 정의할 수 있습니다.
dependencies {
implementation gradleApi()
}5. 빌드스크립트
이전에 보았듯이 의존성 블록 내에서 소스 코드 및 테스트의 외부 의존성을 선언할 수 있습니다 . 마찬가지로 buildScript 블록을 사용하면 타사 플러그인 및 작업 클래스와 같은 Gradle 빌드의 의존성을 선언할 수 있습니다. 특히 buildScript 블록 이 없으면 Gradle의 기본 기능만 사용할 수 있습니다.
아래 에서 Maven Central에서 다운로드 하여 Spring Boot 플러그인 을 사용하겠다고 선언합니다 .
buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath 'org.springframework.boot:spring-boot-gradle-plugin:2.3.4.RELEASE'
}
}
apply plugin: 'org.springframework.boot'따라서 기본 의존성이 없기 때문에 외부 의존성을 다운로드할 소스를 지정해야 합니다.
위에서 설명한 내용은 이전 버전의 Gradle과 관련이 있습니다. 대신 최신 버전에서는 더 간결한 형식을 사용할 수 있습니다.
plugins {
id 'org.springframework.boot' version '2.3.4.RELEASE'
}6. 결론
이 기사에서는 Gradle 의존성, 선언 방법 및 다양한 구성 유형을 살펴보았습니다.
