[Gradle] Gradle Task, 왜 이렇게 많고 헷갈리는 거야?

Gradle 공식 사이트에서 Task LifeCycle을 보면 다음과 같다.

Task LifeCycle

 

compileJava, processResouces, jar, build, clean...
너무 많은거 같은데. 이게 뭘 하는거지..?

 

위 Task LifeCycle 이미지에서 각각의 파란색 사각형들은 Task다.

 

Gradle Task는 크게 "작업 태스크"와 "집계 태스크"로 분류 할수 있다.

작업 태스크 (Action Task)

• compileJava
• processResources
• compileTestJava
• processTestResources
• test
• jar
• clean

작업 태스크는 직접 일을 하는 Task다.

Compile

컴파일(compile) 접두사가 붙은 Task(compileJava, compileTestJava)들은 모두 "번역"이라고 이해하자.

사람이 이해할 수 있는 언어로 작성한 .java 파일들을 컴퓨터가 이해할수 있는 .class 파일로 번역하는것이 컴파일이다.

컴파일(번역)된 .class 파일은 각 태스크마다 아래 경로에 생성된다.

• compileJava : src/main/java/ → build/classes/java/main/
• compileTestJava : src/test/java/ → build/classes/java/test/

.java 파일 경로

.class 파일 경로

Resources

Resources가 들어있는 Task(processResources, processTestResources)들은 정적자원 관리와 연관이 있다.

각 태스크의 결과로 정적 자원들은 아래 위치에 생성된다.

• processResources : src/main/resources/ → build/resources/main/
• processTestResources : src/test/resources/ → build/resources/test/

정적 자원 파일 경로

Test

작성된 테스트 코드를 Junit, Mockito 등의 테스트 프레임워크로 실행한다.

테스트 결과는 아래와 같이 저장된다.

• build/test-results/test/*.xml (테스트 실행의 JVM 바이너리 결과 (XML 포함) 저장)
• build/reports/tests/test/index.html (HTML 테스트 리포트)

테스트 결과 파일 위치

Jar

jar 태스크는 jar 파일을 만든다.

모든 .class 파일, 리소스(application.yml, 정적 파일 등)와 의존성에 포함된 라이브러리들까지 하나로 묶는다.

이 결과는 build/libs/ 아래에 jar 파일로 저장된다.

jar 태스크 실행시 jar 파일 위치

 

※ 참고 : jar 파일의 이름
jar 파일이 "[이름]-[버전].jar" 라고 할때,
1. 일반적으로, setting.gradle.kts 파일에 설정된 rootProject.name이 jar 파일의 [이름]이다.
2. 일반적으로, build.gradle.kts 파일에 설정된 version이 jar 파일의 [버전]이다.
3. build.gradle.kts 파일에서 jar Task의 archiveBaseName, archiveVersion, archiveClassifier 변수를 통해 변경 가능하다

Clean

클린은 초기화다.

build 디렉토리는 Gradle Task들의 결과물들이 모여있는 디렉토리이다.

clean Task는 build 디렉토리 자체를 삭제해서 초기화 한다.

clean 태스크 실행시 build 디렉토리 삭제

 

집계 태스크 (Aggregate Task)

• classes
• testClasses
• assemble
• check
• build

집계 태스크는 직접 일을 하는 Task는 아니다.

집계 태스크를 실행하면 의존하고 있는 다른 태스크들을 실행한다.

위 Task LifeCycle 이미지에서 화살표의 방향을 보면 우측에서 좌측으로 뻗어있는것을 알 수 있다.

이는 Gradle Task 간의 의존관계(Depend On)를 보여준다.

하나씩 살펴 보자.

Classes

classes Task의 화살표는 compileJava, processResources에 뻗어있다.

집계 태스크인 classes를 실행하면 액션태스크인 compileJava 태스크와 processResources를 실행한다.

TestClasses

testClasses Task는 compileTestJava, processTestResources 태스크들을 의존하고 있다. 그런데, compileTestJava 태스크가 classes 태스크를 의존하고 있기 때문에 앞서서 얘기한 compileJava, processResources까지 실행된다.

Assemble

assemble 태스크는 jar 태스크를 실행시킨다.

jar 태스크는 testClasses와 마찬가지로 classes 태스크를 통해서 compileJava, processResources까지 실행한다.

Check

check 태스크는 test 태스크를 실행시킨다.

test는 testClasses 태스크를 실행한다.

따라서 compileTestJava, processTestResources, compileJava, processResources까지 실행된다.

Build

build 태스크는 check태스크와 assemble 태스크를 의존하고 있다.

check 태스크는 test태스크를 실행시킨다.

결과적으로 compileTestJava, processTestResources, compileJava, processResources들을 실행한다.

또한, assemble 태스크는 jar 태스크를 실행시킨다.

결과적으로 compileJava, processResources를 실행한다.

※ 참고

"build 태스크가 test, assemble을 실행시키면 결국, compileJava, processResources는 중복실행 아닌가?"

아닙니다. Gradle은 DAG(Directed Acyclic Graph, 방향 비순환 그래프) 기반의 빌드 시스템으로, 실행 전 태스크 그래프를 분석해 각 태스크가 한 번만 실행되도록 설계 되어 있습니다. 

※ 참고 : Gradle 태스크 상태
EXECUTED (or No Label) : 실제 작업이 실행됨 (입력/출력 바뀌었거나, 강제 실행됨 등)
UP-TO-DATE : 입력/출력에 변경사항 없음 → 작업 생략
FROM-CACHE : 이전 빌드의 결과를 캐시에서 가져와 재사용함.
SKIPPED : 실행 조건이 맞지 않아 건너뜀 (예: onlyIf, enabled = false)
NO-SOURCE : 태스크가 사용할 입력 파일(소스)이 전혀 없음.