JMT Gradle
2018.12.10(월) 에 코드스쿼드에서 발표한 Gradle에 대해서 정리한 글을 공유하겠다
INDEX
1. 그래들이 뭐야?
2. 그래들의 알짜배기 개념
3. build.gradle 파해치기
1. 그래들이 뭐야?
- 2012년 출시된 차세대 빌드 툴
- 이전 세대 빌드 툴(Ant, Maven)의 장점들을 모아서 만듬
최근 스프링 관련 제품 개발이나 기업 솔루션을 중심으로 그래들을 도입하는 사례가 빠르게 증가
가장 큰 특징은 빌드 스크립트를 간단하게 작성이 가능
스크립트가 간단해서 배우기도 쉽고 읽기도 쉬움
(메이븐을 배우려고 했지만 너무 어려워서 좌절했던 사람에게 추천)
- 앤트나 메이븐 같은 기존 빌드 툴의 기능과 시스템을 활용할 수 있음
- 즉, 기존 자원을 최대한 활용하면서 단계적으로 그래들로 이전이 가능해짐
TIP )
Ant의 가장 큰 장점
개발자가 자유롭게 빌드 단위를 지정하고 빌드 단위 간의 의존 관계를 자유롭게 설정할 수 있다.
하지만 자유도가 높다는 것은 잘 활용할 경우 좋은 도구가 될 수 있지만 그렇지 않을 경우 애물단지로 전락할 가능성이 있다.
Maven의 가장 큰 장점
Convention Over Configuration(CoC)전략에 따라 프로젝트 빌드 과정에 대한 많은 부분이 이미 관례로 정해져 있다.
따라서 Maven 기반 프로젝트를 경험한 개발자는 Maven을 기반으로 하고 있는 새로운 프로젝트에서도 쉽게 적응할 수 있다.
하지만 관례가 항상 좋은 것은 아니며, 특수한 상황이 발생하는 경우에는 맞지 않는 경우도 종종 발생한다.
Maven의 관례에 거부감을 가지는 개발자도 있다.
자바 애플리케이션 빌드 과정
빌드 툴을 사용하면 위 빌드 과정을 모두 자동화 해준다!
빌드 툴을 안쓰면..
- 앞서 설명한 일련의 과정을 수작업으로 해야함
- 실수 방지를 위한 확인 작업까지 추가로 해야함
- 수작업으로 하는 인적 비용 발생
- 이 비용을 줄이기 위해 출시 빈도를 줄이기도 함
빌드 툴의 장점
- 정형화된 작업에 사람이 관여하지 않아도 되니 실수가 줄어듬
- 개발에만 집중할 수 있다
- 빌드 스크립트가 항상 관리 되므로 낡은 정보가 될 위험이 줄어듬
빌드 툴의 역사
메이크
- 소프트웨어 개발 세계에 빌드 개념을 처음으로 도입
- 메이크 이전에는 수작업이나 약간의 스크립트 작성을 해야지만 작업이 가능했음
- 하지만 메이크 등장 후 Makefile 이라는 통일된 구조로 처리가 가능해짐
- 기능이 단순
- 플랫폼 의존성이 크다
앤트
- 자바와 XML 기술을 도입하여 플랫폼 의존 문제를 해결
개발자가 자유롭게 빌드 단위를 지정하고 빌드 단위 간의 의존 관계를 자유롭게 설정할 수 있다
(자유도가 높음)
- 간단하고 사용하기 쉽다
- 하지만 약간의 복잡한 처리를 하려면 빌드 스크립트가 장황해져 관리하기 어려워지는 단점이 있다
- 라이브러리 의존관계를 관리하는 구조가 없음
메이븐
- 자바와 XML을 사용해서 플랫폼 독립성을 확보(=앤트)
- 빌드 생명 주기(Lifecycle)와 프로젝트 객체 모델(POM)이라는 새로운 개념을 도입
- Convention Over Configuration (CoC) 전략에 따라 프로젝트 빌드 과정에 대한 많은 부분이 관례로 정해짐
- 앤트의 약점인 장황한 빌드 스크립트 문제를 해결
- POM에 라이브러리 의존관계를 자동으로 관리해주는 기능을 구현
- 빌드 툴 세계에 혁명을 가져왔지만 기능이 많고 어려움 (학습 장벽이 높다)
그레이들
- 지금까지의 빌드 툴이 가진 장점들을 모아서 만듬
- 규칙을 따라 디렉터리 구조를 만드는 규칙 기반 빌드로 빌드 스크립트 내용을 크게 줄일 수 있음(생산성 향상)
- JVM 언어인 그루비 사용
- 그루비는 자바 문법과 거의 같아서 쉽게 익힐 수 있다
- 그래들은 단순한 그루비 문법을 넘어서 빌드 스크립트를 간략히 해주는 자체문법(DSL)을 제공
- 그래들 wrapper(래퍼)를 이용해 그래들이 설치되지 않은 환경에서도 빌드 가능
2. 그래들의 알짜배기 개념
Task
정의
- 그래들을 통해 실행되는 단위를 Tesk라고 한다
- 개발자가 추가하고 싶은 빌드 단위가 있으면 build.gradle 에서 새로운 tesk를 추가할 수 있다
- gradle 명령으로 호출 실행이 가능
사용법
Task 테스크명 {
수행할 처리
}
여기서 << 라는 말이 나오는데 이것은 사실 클로저라는 태스크 축약형이다.
아래 그림을 보자
<< 는 doLast를 축약한 것과 같다.
doLast는 해석 그대로 '마지막에 하라' 라는 뜻으로 '맨처음에 하라'는 뜻을 가진 doFirst도 있다.
퀴즈
task codesquad {
doLast {
println 'NNN'
}
doFirst {
println 'brad'
}
doLast {
println 'soop'
}
}
위의 결과는?
TMI ) 위 예제 인물들은 코드스쿼드 동기 닉네임을 사용했다.
Task 심화
Task 간의 의존관계
위 처럼 task 간의 의존관계를 맺을 수 있다.
brad 태스크를 호출하면 의존관계를 맺고있는 codesquad라는 녀석을 먼저 호출하고 자신인 brad 태스크를 호출하는 구조로 되어있다.
그래서 이것을 활용하면 마치 자바의 상속처럼 중복을 제거하는 것이 가능해 진다.
플러그인
apply plugin : 'jetty'
의미
- 현재 프로젝트에서 jetty 플러그인을 사용하겠다.
- jetty 플러그인에서 제공하는 task와 task간의 의존관계를 현재 프로젝트에 포함 시키겠다
jetty 플러그인의 기본 task
- jettyRun
- jettyRunWar
- jettyStop
jetty 플러그인만 적용한 상태에서 전체 task 목록을 보면 다음과 같다.
위 목록을 보면 jetty 플러그인을 적용할 때 기본적으로 제공하는 jettyRun, jettyRunWar, jettyStop 3가지 이외에도
적용하지도 않은 task들이 추가된 것을 볼 수 있다.
이는 기본 제공 task와 의존관계를 맺고 있는 녀석들도 자동으로 추가된 것이다.
jetty 플러그인의 구조를 살펴보자
jettyRun 태스크는 classes 태스크와 의존관계를 맺고있다
jettyRunWar 태스크는 war 태스크와 의존관계를 맺고있고,
war 태스크는 classes 태스크와 의존관계를 맺고있다
- war 태스크는 war plugin의 기능 => 내부적으로 apply plugin : ‘war’ 추가
- classes 태스크는 java plugin의 기능 => 내부적으로 apply plugin : ‘java’ 추가
jetty 플러그인만 추가했지만 task간의 의존관계로 인해
자동으로 apply plugin : ‘war’ , apply plugin : ‘java’ 를 추가
위와 같이 jetty plugin만 적용하더라도 war plugin과 java plugin과의 의존관계가 발생하기 때문에 실제 프로젝트에서는 상당히 많은 task가 추가된다는 것을 알 수 있다.
내장 태스크
- 태스크 정의를 하지 않았는데도 기본적으로 정의되어 있는 태스크
- 태스크 목록은 $ gradle tasks 로 확인할 수 있다
터미널 상에서 위와 같이 $ gradle tasks 를 이용하여 전체 task를 확인할 수 있으며,
별도의 터미널 작업 없이 인텔리제이 안에서도 확인이 가능하다.
프로젝트 자동 생성
내장 태스크인 init 을 이용하면 디렉터리를 자동으로 생성할 수 있다
프로젝트 구조를 Java library 구조로 만들기
- $ gradle init–type java-library
src/main/java : 배포할 자바 소스 코드(production code) 디렉토리
src/main/resources : 배포할 설정 파일 디렉토리
src/test/java : 테스트 자바 소스 코드(test code) 디렉토리
src/test/resources : 테스트시 필요한 설정 파일 디렉토리
gradle/ wrapper 디렉토리
그래들 래퍼
- 내장 태스크 wrapper
- 개발자들이 직접 그래들을 설치하지 않아도 빌드가 가능해짐
- 그래들을 설치하는 사람은 한 사람만 있으면 충분
3. build.gradle 파해치기
해당 내용은 코드스쿼드에서 진행하고 있는 java-qna 프로젝트의 build.gradle을 기반으로 설명
댓글