자바 프로젝트를 구성할 때 빌드를 gradle로 선택해 생성하면, build.gradle, gradlew, gradlew.bat 등 다양한 gradle 관련 파일들을 볼 수 있다. 그냥 이렇게 구성해라 하는 튜토리얼만 봤지 이게 뭔지 궁금해본 기억은 없다. 프로젝트를 진행할 때도 슬슬 고민을 해볼 때인 것 같다는 생각이 들었고, 이번 기회에 한 번 파헤쳐봤다.
1. Gradle이란?
우리가 생성하는 Java 코드들(.java 파일들)이 실행 가능한 소프트웨어로 변환되기 위해서는 빌드 과정을 거쳐야 한다. 빌드는 소스 코드를 컴파일 할 뿐만아니라 dependency를 추가해주고 실행가능한 bundle(묶음 파일)을 생성한다. 빌드 과정은 컴파일 → 링킹 → 패키징 → 테스트로 이루어진다.
이렇게 빌드를 끝내면 JAR, WAR 파일 등이 생성될 수 있다. 이렇게 생성된 결과물을 Artifact라고 부른다.
JAR(Java Archieve)파일은 자바에서 사용되는 압축 양식으로 클래스 + 리소스 파일로 구성된다. WAR(Web Archieve) 파일은 웹 애플리케이션을 압축하고 배포하는데 사용되는 압축 파일로써 JAR에 비해 Java Sevlet, XML 파일, 정적 파일 등 추가되는 자원들이 더 많아진다.
이런 빌드 과정은 개발자가 필요한 라이브러리와 소스코드의 classpath를 직접 명시해주고, 그것을 통해 생성할 수 있지만, 이런 귀찮은 작업들은 이미 자동화가 되어있다. Maven이나 Gradle이 해당 자동화 빌드 툴에 해당한다.
Maven은 pom.xml에, Gradle은 build.gradle 파일에 빌드 작업을 각 빌드 툴에서 제공하는 명세 혹은 DSL로 작성하게 된다. 그러면 빌드 툴들은 해당 파일을 읽고 어떻게 Artifact를 생성할지 생각한 후 만든다
2. Gradle 구성 요소
자, 우리는 Gradle이 어떤 역할을 하는지, 어떤 정보를 통해 개발자와 상호작용하여 Artifact를 만들어내는지는 알았다. 그럼 Gradle은 어떤 파일들을 통해서 빌드를 수행하는지 한 번 알아보자.
하나의 Gradle 프로젝트를 생성하면 기본적으로 아래의 파일들이 생성된다.
├── build.gradle
├── gradlew
├── gradlew.bat
├── settings.gradle
├── gradle
│ └── wrapper
│ ├── gradle-wrapper.jar
│ └── gradle-wrapper.properties
└── src
├── main
│ └── ...
└── test
│ └── ...
주요 구성 요소는 build.gradle, gradlew (gradlew.bat), settings.gradle이다. 각각이 어떤 역할을 하는지 확인해보자.
1) build.gradle
앞서 언급했듯, gradle로 빌드를 하면 (gradle wrapper로 빌드하면) build.gradle에 적힌대로 build된다. 그럼 build.gradle에 적힌 각 요소들은 뭘 나타내는 것일까?
아래 사진은 우테코 프리코스에서 진행한 아주 간단한 애플리케이션의 build.gradle 파일이다.
plugins, repositories, dependencies, java, test의 항목으로 이루어진 것을 확인할 수 있다. java와 test는 하나의 task로써 java는 plugin에서 사용되고, test는 테스트시 사용된다. 때문에 이외의 항목 각각에 대해서 알아보자.
(참고로 task는 하나의 작업들을 묶어놓은 블록같은 것이다. gradle에는 java task가 포함되어 있는데, gradle java 명령을 실행하면 java task에 적힌 명령이 실행된다.
plugins
plugin은 미리 구성한 features, compile된 Java 코드, JavaCompile 등의 Task, SourceSet 등의 domain object 가져오기, convention 지정 등 다양한 객체들을 추가할 수 있다. 요약해보자면 아래와 같다.
- 새로운 DSL elements들을 추가하는 등 Gradle 모델 확장
- 새로운 task 추가나 defaults 구성 등 지정된 convention에 따라 project를 구성
- organizational repositories를 추가하거나 기준을 강제시키는 등 특정 configuration 적용
repositories
repositories는 아래 기술할 dependecies에 따라 사용하는 라이브러리들을 자동으로 다운로드하는 위치를 지정한다. 즉, gradle을 통해 빌드를 하게 되면, 해당 저장소 위치에서 필요한 라이브러리들을 다운로드한다.
dependencies
dependencies는 프로젝트에서 사용하는, 필요한 라이브러리를 지정한다. 이때 build 라이프 사이클의 적절한 시점에서 classpath에 추가해준다. 예를 들어 test시에만 사용할 라이브러리를 지정할 수 있고, compile time, runtime 각각에만 사용될 의존성들이 있을 수 있다. 개발자가 이를 build.gradle에 이를 명시하면 빌드 툴은 해당 시점에 맞는 의존성들을 추가한다.
이렇게 맞는 사이클에만 적절하게 추가하는 경우 다음과 같은 장점이 생긴다.
- 컴파일이 빨라진다. (compile 할 때 사용할 일 없는 dependency를 classpath에서 뺀다면 빨라질 수 있다.)
- 코드 작성 시, runtime classpath에 있어야하는 dependency를 실수로 사용하는 것을 미연에 방지할 수 있다.
- classpath 목록을 깔끔하게 정리하는 것도 편해진다.이렇게 필요할 때만 의존성을 추가해준다면 여러 장점이 생긴다.
test
test는 gradle을 통해서 test를 수행할 때 사용한다. 예를 들어 터미널에서 gradle test를 입력하면, 어떤 작업을 통해 test를 수행할지 명시하는 것이다. 이 또한 task의 일종.
2) Gradle Wrapper (gradlew, gradlew.bat)
Gradle Wrapper는 Gradle을 각 개발자나 CI 서버에 깔지 않고, 프로젝트에 함께 포함시켜 배포할 수 있는 방법을 제공해준다. gradle의 선언된 버전을 호출해 미리 다운로드해 빌드를 준비하고 gradle 프로젝트를 빠르게 실행시킬 수 있도록 돕는다.
Wrapper를 사용하는 이유
Gradle 빌드를 실행하는데 권장되는 방법은 Gradle Wrapper(gradlew)를 사용하는 것이다. Wrapper는 선언된 버전의 Gradle을 호출해 필요한 경우 미리 다운로드하는 스크립트 이다. 결과적으로 수동 설치 프로세스를 수행하지 않고도 Gradle 프로젝트를 신속하게 시작할 수 있게 된다.
즉, Graddle Wrapper를 사용하면 이미 존재하는 프로젝트를 새로운 환경에서도 바로 빌드할 수 있게 되며 Java나 Gradle을 따로 설치할 필요가 없어진다. 환경에 종속되지 않게 되는 것.
생성 방법
프로젝트 폴더에서 그냥 gradle wrapper 명령을 치면, gradlew 파일이 생성된다.
# 그냥 실행
gradle wrapper
# 옵션을 사용하는 경우
gradle wrapper --gradle-version 6.0.1 --distribution-type all
gradle build를 사용하면 컴퓨터에 설치된 gradle과 java를 기준으로 build 하며, gradlew build를 실행하면 build.gradle 파일에 정의한 내용을 기준으로 build된다.
gradlew와 gradlew.bat의 차이는 사용환경의 차이이다. 과거에는 윈도우에서 gradlew.bat만 사용가능한 듯 했으나, 지금 필자의 컴퓨터인 윈도우10에서는 gradlew로도 빌드가 가능하다.
- Linux, OSX, MacOS: gradlew 사용
- Window: gradlew.bat 사용 (gradlew도 사용할 수 있음)
이후 해당 파일을 사용해 build하고 싶다면 ./gradlew build를 실행하면 된다. 그냥 gradle build 명령어를 사용하면 컴퓨터에 설치된 gradle과 java를 기준으로 build가 되며, 위의 ./gradlew build를 실행하면 build.gradle에 정의한 내용을 기준으로 build가 된다.
3) Setting.gradle
setting.gradle은 빌드 이름과 하위 프로젝트를 정의하며, 빌드 대상이 되는 프로젝트를 설정하는 스크립트.
rootProject.name = 'DBMigrator'
해당 프로젝트와 하위 프로젝트들 사이의 관계 및 프로젝트의 구성 정보를 기록하는 파일이다. 사용자 정보 및 실행환경 초기화 등으로 응용할 수 있다. 우선 작성하면, gradle은 해당 파일에 기술된대로 프로젝트를 구성하게 된다.
예를 들어
rootProject.name = 'fleamarket'
include 'marketbatch'
include 'marketcrawler'
이렇게 구성하면, fleamarket 프로젝트의 하위 프로젝트로 marketbatch, marketcrawler를 포함할 수 있다. 이후 최상위 프로젝트인 fleamarket 프로젝트의 build.gradle에 subprojects에 대한 설정을 추가한다면, 모든 하위 프로젝트에 해당 설정을 적용시킬 수 있다.
마무리
지금껏 모든 자바 프로젝트를 gradle로 구성하면서, gradle에 대한 궁금증을 가져본 기억이 없었다. 앞으로는 여러 프로젝트들과 연동시켜야하는 프로젝트를 구성하거나 혹은 의존성에 대한 미세한 조정을 신경 쓸 수 있을 것 같다.
Reference
운영 자동화#1 — 빌드 자동화 by Gradle
개발자가 비지니스 로직 구현에 집중하기 위한 운영 자동화의 첫번째 단계로 Gradle을 활용한 빌드 자동화에 대해서 설명한다. 개발에 대한 아주 기본적인 내용과 직접 Gradle 플러그인을 만드는
medium.com
https://docs.gradle.org/current/userguide/userguide.html
Gradle User Manual
docs.gradle.org
https://kwonnam.pe.kr/wiki/gradle#gradle
gradle [권남]
kwonnam.pe.kr
'Java' 카테고리의 다른 글
| Java의 Error, Exception, 그리고 Checked와 Unchecked (0) | 2022.11.22 |
|---|---|
| 왜 Generic에 Primitive Type은 사용하지 못할까? (0) | 2022.10.25 |
| Double-Checked Locking In Java (0) | 2022.10.22 |
댓글