Gradle 프로젝트 소스를 실행할 때, 로컬 컴퓨터에 프로젝트와 동일한 버전의 gradle 이 필요할 수 있는데 Wrapper 를 사용하면 해당 버전을 수동 설치할 필요가 없다. Gradle Wrapper 를 사용하면 지정된 버전의 gradle 이 없을 경우 자동으로 다운로드 및 설치를 하여, 해당 프로젝트를 동일한 gradle 버전으로 빌드할 수 있다. 구성원들의 안정적이고 표준화된 실행을 보장하기 위해 항상 Wrapper 로 빌드를 실행하는 것을 권장한다.

1. Wrapper 파일 생성

누군가 해당 소스를 받아서 Wrapper 를 사용할 수 있게 하려면, 미리 wrapper 파일을 생성해야 한다. 이 때는 gradle 이 로컬 컴퓨터에 설치되어 있어야 한다. 기본적으로 Gradle 프로젝트를 생성하는 init task 로 wrapper task 까지 실행된다. wrapper task 는 "Build Setup" 그룹에 존재하며, 이를 실행할 경우 프로젝트 디렉토리에 wrapper 파일을 생성해 준다.

$ gradle wrapper

gradle/wrapper/gradle-wrapper.jar
gradle/wrapper/gradle-wrapper.properties
gradlew(.bat)

• jar 파일은 properties 파일에 기반하여 Gradle 배포판을 다운로드하는 코드가 포함된다.
• gradlew 파일은 Wrapper 로 빌드를 실행하기 위한 스크립트이다.
• properties 파일에는 gradle 버전과 배포판 타입을 선택할 수 있으며 기본적으로 사용중인 gradle 버전을 따른다.

명령줄에서 직접 버전과 배포판 타입을 지정하여 wrapper 파일을 생성할 수도 있고,

$ gradle wrapper --gradle-version 7.2 --distribution-type all

이미 민들어진 properties 파일을 수정하여 동일한 결과를 만들 수도 있다.

distributionUrl=https\://services.gradle.org/distributions/gradle-7.2-all.zip

2. Wrapper 사용

$ gradlew build

※ IDEA 에서의 Gradle 설정

Wrapper 를 활용하는 가장 일반적인 방법은 프로젝트 생성하는 사람이 Wrapper 설정까지 마쳐놓고, 다른 개발자들이 IDEA 설정에서 wrapper 파일을 사용하도록 설정하는 것이다. 

간혹 수동으로 설치한 gradle 과 프로젝트 설정의 gradle 버전에 혼동을 느낄 수 있다. 로컬에서 프로젝트 gradle 버전 설정은 [File] - [Settings...] - [Build, Execution, Deployment] - [Build Tools] - [Gradle] 에서 설정한다. 그렇게 설정한 버전은 [View] - [Tool Windows] - [gradle] 창에서 사용된다.

하지만 [View] - [Tool Windows] - [Terminal] 에서의 gradle 은 수동 설치 후 로컬 컴퓨터의 환경 변수에 지정된 gradle 버전과 연결되어 있다. Terminal 에서 프로젝트 디렉토리 안에 있더라도 [Settings...] 에서 설정한 프로젝트의 gradle 버전과 연관이 없다. IDEA Terminal 이지만 CMD 와 같다.  [File] - [Settings...] - [Tools] - [Terminal] 에서 사용할 터미널 종류를 선택할 수 있다.

You can configure gradle wrapper to use distribution with sources. It will provide IDE with Gradle API/DSL documentation.

IDEA 에서 gradle-wrapper 사용시 배포판 타입이 바이너리 전용 파일을 사용하도록 설정되어 있는 경우 발생하는 알림이다. 수락하면 docs/source 를 포함한 all 버전의 gradle 로 설치되고 사용된다. (무시해도 상관없음)

Gradle 설치 파일의 배포판 타입(DistributionType).

1. gradle-version-bin.zip (bin: 바이너리만)
2. gradle-version-all.zip (all: docs, source 포함)

build.gradle 에 복붙하니 에러난다.

provided() 메소드가 없단다.

컴파일에만 사용(런타임 안사용) 하기 위한 provided 범위를 지정하는 방법은 세가지.

1. configurations 와 sourceSets 에 provided 설정.
2. war plugin 으로 providedCompile 설정.
3. java plugin 의 compileOnly 설정.

mvn repository 에서 아무 설정없이 사용할 수 있는 compileOnly 를 사용하지 않고, provided 를 사용한 이유를 모르겠다.

구버전 gradle 를 사용하는 자들에 대한 배려인지, 아니면 compileOnly 와 provided 의 기능에 어떤 보이지 않는 차이가 있는건지...

빌드 관리 툴로써 이 둘 중 하나를 고민한다면 어느 것이 나을까.

정답이 있는 건 아니지만, 처음 빌드 관리 툴을 사용하는 입장이라면 gradle 을 추천하고 싶다.

일단 maven 보다 나은 점을 꼽아보자면, 빠른 성능과 간결한 설정을 들 수 있다. https://gradle.org/maven-vs-gradle/ 참고.

아무래도 maven 의 단점을 보완한 최신 툴이고, 계속해서 많은 버전 업그레이드를 진행하고 있어 그 격차가 계속 벌어지고 있는 듯 하다.

동일한 역할을 하는 툴이므로 maven 에 익숙한 분들은 굳이 약간의 성능을 느끼기 위해 gradle 로 갈아타려 하지 않을 수도 있다.

빌드만 잘되면 그 뿐이지만... gradle 의 엄청난 기능들과 확장성을 공부한다면 마음이 바뀔 수도 있을지 모른다.

아래는 Maven 과 Gradle 의 간단한 비교이다.

gradle 의 빌드 스크립트는 groovy 라는 언어로 작성해야 하므로 maven 의 xml 에 비하면 친숙하진 않지만 확장성이 뛰어나다.

maven 은 프로젝트가 커질수록 빌드 스크립트의 내용이 길어지고 가독성이 떨어지는 반면, gradle 은 훨씬 적은 양의 스크립트로 짧고 간결하게 작성할 수 있다.

maven 의 경우 멀티 프로젝트에서 특정 설정을 다른 모듈에서 사용하려면 상속을 받아야 하지만 gradle 은 설정 주입 방식으로 이를 해결한다.

그래서 gradle 은 멀티 프로젝트에 매우 적합하며, 빌드 속도는 다양한 시나리오 상에서 10~100배 가량이 빠르다.

선택은 자유.