Gradle 요약

 

IntelliJ 쓰면서 간간히 봤던 Gradle

Gradle 이 대체 뭘까? 

 

 

출처 : https://docs.gradle.org/current/userguide/what_is_gradle.html#five_things

 

---

Gradle

 

오픈소스 빌드 자동화 툴로 어떤 타입의 소프트웨어든 빌드할 수 있을 만큼 유연한 특징이 있다.

 

 

Gradle의 중요한 특징들

 

- 휼륭한 퍼포먼스

Gradle은 불필요한 작업의 수행을 피하기 위해 입출력이 바뀔 때 필요한 작업만 수행합니다. Build cache를 사용하여 지난 작업의 출력물 혹은 다른 기계의 출력물을 재사용 가능합니다. 또한 여러가지 최적화 기능이 탑재되어 있고 개발팀이 계속해서 Gradle의 퍼포먼스를 키우기 위해 노력하고 있습니다.

 

 

- JVM foundation

Gradle은 Java Development Kit (JDK)가 설치되어 있는 JVM에서 작동합니다.

이 덕분에 여러 Java API, plugins를 같이 사용 가능하며 다른 플랫폼에서도 Gradle이 쉽게 작동 가능하게 합니다.

그렇다고 해서 Gradle이 JVM 프로젝트를 생성하는 데에만 사용되는 것은 아닙니다. 

 

 

 

- Conventions

Gradle 은 Maven's book을 참조한 convention 들을 적용하여 Java 프로젝트 같은 일반 프로젝트를 쉽게 생성합니다. 

적절한 플로그인을 적용하여 많은 프로젝트에 사용할 가볍고 짧은 빌드 스크립트를 쉽게 짤 수 있습니다. 하지만 이러한 convention들에 Gradle은 덮어쓰기를 허용합니다. 원하는 작업을 추가하시고 convention 기반 빌드에 사용자가 정의한 기능을 추가하세요

 

 

 

- IDE support

 

여러 메이저 IDE ( Android Studio, IntelliJ IDEA, Eclipse, and NetBeans)는 Gradle 빌드를 import 하는 것이 가능합니다.

Gradle은 Visual Studio에 load 가능한 solution file을 생성하는 기능도 지원합니다.

 

 

 

- Insight

 

Build scans 기능은 build run을 실행했을때 어떤 문제가 있었는지 확인할 수 있도록 방대한 양의 정보를 제공합니다.

이 정보는 build 문제를 확인하는데에 많은 도움을 줍니다 이 build scan을 타인과 공유 가능하고, 빌드 문제에 조언을 받기가 쉬워집니다.

 

 

 

 

---

Gradle에 대해서 알아야할 5가지 

 

Gradle은 유연하고 강력한 빌드 툴이지만 처음 사용할 때는 어려움을 쉽게 느낍니다. 하지만 Gradle을 사용하기 전 5가지의 핵심 원리를 이해한다면 Gradle에 더욱 쉽게 다가갈 수 있을 것이고 알아채기도 전에 Gradle 숙련자가 되어 있을 것입니다.

 

 

1. Gradle은 범용(general-purpose) 빌드 툴입니다

 

Gradle은 어떤 소프트웨어도 빌드 가능하게 해 줍니다. 왜냐하면 당신이 무엇을 빌드하려고 하는지, 어떻게 빌드해야 할지에 대한 가정을 적게 하기 때문입니다. 가장 주목할 만한 제한사항은 현재 의존성 관리가 Maven- 과 Ivy-compatible repositories와 filesystem만 지원하는 점입니다.

 

이러한 점이 build를 생성하는데 많은 작업을 해야 하는다는 것을 의미하지는 않습니다. Gradle은 일반 타입의 프로젝트 (예 : Java Libraries )를 conventions와 plugin을 이용한 prebuilt functionality를 추가하는 방식으로 쉽게 생성할 수 있도록 합니다. 물론 사용자 정의 플러그인을 생성 또는 편집하여 개인의 convention 혹은 build functionality를 encapsulate 할 수 있습니다.

 

 

2. The core model is based on tasks - 핵심 모델은 task들에 기반함

Gradle은 자신의 build를 Directed Acyclic Graphs(DAGs) - ( 유향 비순환 그래프 ) of tasks(units of work) 모델로 삼습니다. 이것은 하나의 build가 DAG를 생성하기 위해 task의 집합을 구성하고 서로의 의존성에 근거하여 서로를 연결시킨다는 의미입니다. Task graph 가 생성된 후에는, Gradle이 어떤 순서로 task를 실행할지 결정한 후 task들을 실행시킵니다. 

  

 

3. Gradle has several fixed build phases - Gradle은 여러 개의 고정된 build phases(단계)가 존재

Gradle이 build script들을 세 가지 단계로 평가하고 실행함을 이해하는 것은 매우 중요합니다.

 

 

1. Initialization : 초기화

 

   Build를 위한 환경을 설정하고 어떤 프로젝트가 참여할지 결정

 

 

2. Configuration : 구성

 

  Build를 위한 task graph를 생성하고 구성한 뒤, 사용자가 작동시키고 싶은 task에 따라서 어떤 순서로 task를 수행할지 결정합니다. 

 

 

3. Execution : 실행

 

  configuration phase ( 구성 단계 )에서 마지막에 선택된 task를 실행시킵니다. 

 

 

잘 설계된 build script들은 대부분 imperative logic(명령적 논리) 대신 declarative configuration(선언적 구성)을 포함합니다. 구성 단계에서 구성이 타당하게 평가된다는 뜻입니다. 

 

 

 

4. Gradle is extensible in more ways than one - Gradle은 한 가지 이상의 방법으로 확장 가능

Gradle에 포함된 build logic 하나만으로 모든 프로젝트를 build 할 수 있다면 정말 좋겠지만 거의 불가능합니다.

대부분의 build는 특수한 요구사항이 존재하므로 사용자 정의 build logic을 추가해야 합니다.

 

 

Gradle은 확장 가능한 여러 개의 mechanism을 포함합니다. 예로

 

1. Custom task types

 

    현재 존재하는 task가 할 수 없는 일을 build가 하기를 바란다면 새로운 task type을 작성하면 됩니다. 일반적으로 작성한 task type의 소스 파일을 buildSrc 디렉터리 혹은 packaged plugin에 넣는 것이 제일 좋습니다. 이렇게 하면 작성한 task type을 Gradle이 제공한 task type처럼 사용 가능합니다.

 

 

2. Custom task actions

 

    task가 수행되기 전 혹은 수행 후에 실행할 사용자 정의 build logic을 Task.doFirst()와 Task.doLast() 메서드를 통해 부착할 수 있습니다.

 

 

3. Extra properties on projects and tasks

 

   자기 자신이 만든 특성들을 프로젝트 혹은 task에 추가 가능하고 후에 자신이 정의한 actions 혹은 다른 build logic에도 추가 가능합니다. 추가된 특성들은 명시적으로 사용자를 위해 만들어진 task에도 추가 가능합니다. ( 예로 Gradle의 핵심 플러그인에서 생성된 task )

 

 

4. Custom convention

 

    Convention들은 사용자가 이해하고 사용하기 쉽도록 build를 단순화하는 강력한 방법입니다. 이러한 convention은 Java build와 같이 표준 프로젝트 구조와 표준 naming convention을 사용하는 build에서 볼 수 있습니다. convention을 제공하는 plugin을 스스로 작성할 수 있습니다. build와 관련된 default value 만 구성하면 됩니다.

 

 

5. Custom model

 

        Gradle은 task들, 파일들, 의존성 구성을 넘어선 새로운 콘셉트를 빌드에 적용하는것을 허용한다. Build에 source sets 컨셉을 추가하는 대부분의 언어 플러그인에서 이러한 점을 확인할 수 있다. 빌드 프로세스에 적절한 모델링을 적용하면 빌드의 효율성과 사용성을 크게 늘릴 수 있다. 

 

 

5. Build scripts operate against an API - Build script들은 API와 대항하여 작동됨 ( 서로 좋지 않은 영향을 주며 작동 )

Gradle의 build scipt를 executable code (실행 가능한 코드)로 생각하기 쉽지만 (실제로 executable code 이기 때문 ) implementation detail 일 뿐이다 -> 잘 설계된 build script들은 소프트웨어를 build 하기 위한 단계들을 어떤 방식으로 수행할지 설명하는 것이 아니라 어떤 단계가 필요한지 설명하기 때문. 단계들을 어떤 방식으로 수행할지 결정하는 것은 custom task types와 plugin들의 역할.

 

Gradle의 좋은 능력과 유연성이 build script들이 코드인 덕이라는 건 자주 있는 오해. 내부의 모델과 API 덕분에 좋은 능력이 있는 것. 명령적인 논리를 가능하면 아예 추가하지 않거나, 최소한의 build script를 추가하는 것을 추천.

 

Build script를 실행 가능한 코드로 보는 것이 좋은 영역이 하나 있긴 하다: Build script의 구문이 어떻게 Gradle의 API에 연결되는지 이해할 때이다. API 문서는 메서드와 속성들을 나열하고 있고 closures와 action들을 참조하고 있다. Build script 내부에서 이러한 내용이 무슨 의미를 지닐까? Groovy Build Script Primer를 확인해서 API 문서를 더 잘 활용해보자.

 

Gradle이 JVM상에서 작동하면, build script들 또한 표준 Java API를 사용 가능하다. Groovy build script들은 추가적으로 Groovy API들을 사용할 수 있지만 Kotlin build script들은 Kotlin API 사용불가

 

 

 

 

간단 요약

 

1. 빌드 자동화 툴

2. 유연하고 성능 좋음

3. 어떤 소프트웨어든 빌드 가능

4. 확장 가능, 범용성 좋음

5. API 도 사용 가능