목표

1. 빌드 도구 발전의 역사를 이해한다.
2. Make, Ant, Maven, Gradle에 대해 정리한다.
3. Gradle Document 기능 요약을 해석한다.
4. 핵심적으로 알아야 할 기능을 중점적으로 번역하고 정리한다.

Gradle의 역사

✏️사전지식
빌드와 컴파일
컴파일 : 컴파일러에 의해 소스코드가 바이너리 코드로 변환되는 과정
빌드 : 소스코드 파일들을 컴퓨터에서 실행 가능한 소프트웨어 결과물로 만드는 과정
컴파일 -> 빌드 -> 런

자바 빌드 도구

• 계속해서 늘어가는 라이브러리의 추가, 버전 동기화의 번거로움을 줄여줌
  • 이전에는 lib 폴더 하위 jar 파일로 필요한 라이브러리를 직접 추가해주었다.
  • 개발자들 간에 버전관리가 힘들었다.
  • 인증되지 않은 경로에서 다운로드 받은 jar를 사용함으로써 보안 위험이 존재했다.

빌드도구의 발전

	처리 기반	규칙 기반
스크립트(동적)	메이크	그레들
XML(정적)	엔트	메이븐

Make와 Ant

🔎1세대 Make

• '빌드' 개념을 확립
• Unix 계열의 OS에서 사용
• 이전에 수작업으로 수행했던 빌드 과정을 Makefile이라는 통일된 구조로 처리할 수 있게 함.

🔎2세대 Ant

• 범용성을 높임 (크로스 플랫폼 대응)
  • 🤔크로스 플렛폼 : 멀티 플렛폼의 동의어, 컴퓨터 프로그램/운영 체제/컴퓨터 언어/프로그래밍 언어/컴퓨터 소프트웨어 등이 여러 종류의 컴퓨터 플랫홈에서 동작할 수 있다는 것을 뜻한다. (대표적인 예 : Java)
• 1990년 자바의 등장
• 메이크를 자바에 적용하려다보니 문제가 많았고, 이를 보완하기 위해 탄생하였다. (메이크는 C언어로 개발된 S/W를 빌드할 때 아직 사용되고 있다.)
• Java + XML 기술을 도입함으로써 메이크의 문제점이었던 플렛폼 의존 문제를 해결
• 간단하고 사용하기 쉽지만, 약간만 복잡한 처리를 하려고 하면 빌드 스크립트가 장황해져 관리가 힘들다.
• 라이브러리 의존 관계를 관리하는 구조가 없다.

Maven

• 3세대 빌드 도구
• 빌드 스크립트 작성 '효율'을 높임(규칙 기반)
• 빌드 생명 주기와 프로젝트 객체 모델(POM) 개념을 도입 → Ant의 문제점이었던 장황한 빌드 스크립트 문제를 해결하였다.
• POM에 메타 데이터를 적용하여 라이브러리 의존관계를 자동으로 관리해주는 기능을 구현
  • POM은 메이븐에게 어떤 것과 관련있는 프로젝트인지, 소스로부터 output을 생성하는 기본 행동을 어떻게 수정해야할지를 알려준다.
  • POM의 주요 내용은 소스가 어디 있는지, 리소르는 어디 있는지, 패키징은 무엇인지에 대한 기술이다.
  • 메이븐 중앙 저장소를 제공 - 의존 라이브러리 관리
  • 네트워크를 통해 연관된 라이브러리를 함께 업데이트 지원
• web.xml : Java 웹 어플리케이션을 기술하고 설정하고 변경하는 방식을 정의한 파일
• 📌멀티 프로젝트의 구성이 상속 관계로 돼있음 → 공통 설정을 여러 프로젝트가 공유할 때, 빈 프로젝트를 만들어 공통 설정을 넣고 이를 상속하게 만들어야한다.
• pom.xml 설정이 길어짐에 따라 가독성 저하 (한계)

Gradle

• 4세대 빌드 도구
• 스크립트 언어로 회귀하여 유연성을 증대
• JVM위에서 동작하는 Groovy라는 언어로 작성돼있다.
  • Groovy : 스크립트 언어로서 소스 코드를 그대로 실행한다.(컴파일할 필요X)
  • 동적인 빌드는 Groovy 스크립트로 플러그인을 호출하거나 직접 코드를 작성하면 된다.
  • 메이븐의 xml 형태보다 가독성 우수
• 메이븐보다 빠르다.
• 기존의 Maven 이나 Ivy등과 같은 빌드 도구들과도 호환이 가능
• Configuration Injection 방식
  • 주입 시 프로젝트의 조건을 체크할 수 있어서 프로젝트 별로 조금씩 다른 설정이 가능하다.
  • 공통 구성만 주입하고 프로젝트 별로 상이한 점은 그 부분만 따로 주입시킬 수 있다.
• build.gradle에 설정

🔎추가학습

스크립트언어

• Python, Java Script, ruby, php 등
• 인터프리터를 사용해 코드를 한 줄 씩 즉시 해석하고 실행
• 즉, 컴파일러에 의한 변환과정이 없다.
• OS에 무관하게 같은 방식으로 실행
• 매번 프로그램을 실행할 때마다 코드를 한 줄 씩 번역하고 실행
• 코드가 실행되기 전까지 버그를 인지할 수 없다.
• 따라서 디버깅이 까다로움

컴파일언어

• Java, C++, C 등
• 소스코드를 바이너리 코드로 변환한 뒤 실행
• OS마다 다르게 컴파일한다.
• 컴파일된 코드가 존재하는 경우, 프로그램 실행 시 해당 코드만 바로 사용할 수 있음
• 코드의 극히 일부만 수정하는 경우에도 프로그램 중단→코드 수정→컴파일→실행이라는 일련의 과정 수행

비교

	스크립트언어	컴파일언어
실행방식	인터프리터 사용-코드 한 줄 씩 즉시 해석하고 실행	컴파일러 사용-소스코드를 바이너리 코드로 변환한 뒤 실행
OS에 따른 변경사항	OS에 무관하게 같은 방식	OS마다 다르게 컴파일
특이사항	프로그램 실행 시 매번 코드 번역	컴파일한 코드 존재할 시, 해당 코드 바로 사용가능
버그 인지	코드가 실행될 때까지 알 수 없음	컴파일에러로 분류, 실행 중단
코드 수정	코드 수정하고 인터프리터 재실행	프로그램 중단 후 코드 수정, 재컴파일, 실행
e.g.	Python, Java Script, ruby, php 등	Java, C++, C 등

Gradle Document

요약

Gradle 기능 목록 - Gradle의 일부 기능을 이해하는데 도움을 준다.
ref. https://gradle.org/features/

Running Gradle Builds

Gradle 빌드를 실행하는 개발자에게 필요하며, Gradle을 실행하는 모든 사람이 활용할 수 있다.

perfomence

✔️Incremental Builds - 점진적 빌드
Gradle은 빌드 실행 중 마지막 빌드 호출 이후에 task의 입력, 출력 혹은 구현이 변경됐는지 확인한다. 최신상태로 간주되지 않는다면 빌드는 실행되지 않는다. Gradle은 configuration 또한 작업 변경 이력의 일부로 간주한다.

✔️Build Caching - 빌드 캐싱
task가 이미 다른 컴퓨터에서 실행된 경우 Gradle은 로컬 실행을 건너뛰고 빌드 캐시로 부터 작업의 결과물을 가져올 수 있다. 일반적인 사용 사례는 CI 빌드를 공유 빌드 캐시에 푸시(push)하고 개발자가 이를 풀(pull) 할 수 있도록 하는 것이다. 로컬 빌드 캐시를 사용해 동일한 머신에서 이전에 생성된 task의 결과물을 재사용할 수도 있다. Android, Kotlin, C++, Scala를 포함한 여러 플러그인도 task level의 캐싱을 지원한다.

✔️Incremental Subtacks - 점진적 서브 테스크
빌드 실행 중 Gradle이 task의 입력 또는 출력이 변경됐음을 발견하면 작업이 재실행된다. 작업은 incremental API를 사용하여 정확히 변경된 파일을 학습할 수 있다. 이 정보를 이용하면 작업 전체를 rebuild할 필요가 없다.

✔️Incremental Annotation Processing - 점진적 어노테이션 처리
지원되는 어노테이션 프로세서가 있는 경우, Incremental compilation의 효율을 크게 향상시킨다.

✔️Compiler Daemon
컴파일 프로세스를 복제(fork)해야하는 경우, Gradle은 다중 프로젝트 빌드 내에서 재사용되는 daemon process를 생성한다. 이는 컴타일 과정에서 속도를 크게 향상시킨다.

✔️Parallel Execution - 병렬 실행
Gradle은 Worker API를 통해 task 간의 병렬 실행을 허용한다. 병렬 처리는 매우 세분화돼 성능이 빨라진다.

✔️Parallel Download of Dependencies - Dependency의 병렬 다운로드
Gradle은 dependency metadata(typically pom.xml)와 아티팩트(artifact=jar)를 병렬로 다운로드한다. -이는 아티팩트가 실제로 필요한 경우에만 수행된다.

✔️Task timeouts
모든 task에는 실행 시간을 제한하는데 사용하는 timeout 속성이 있다. task가 timeout되면 작업 실행 스레드가 중단되고 빌드가 끝난다.

Build Scans

✔️Web-based Build Visualization - 웹 기반 빌드 시각화
텍스트 콘솔이나 텍스트 파일 대신 웹 인터페이스를 사용해 빌드에서 발생한 상황을 모니터링 할 수 있다. 빌드 스캔은 더 많은 정보를 보다 효과적으로 제공한다.

✔️Collaborative Debugging - 협업 시 디버깅
동료와 빌드 스캔을 공유하여 문제를 효율적으로 해결/개선 할 수 있다. 로깅 출력 라인과 같은 빌드의 특정 측면에 초점을 맞춘 전체 스캔 또는 링크를 공유할 수 있다.

✔️Extend and Customize
캐그, 값, 링크로 빌드 스캔을 작성하기 위해 고유 데이터를 추가해라. 빌드 스캔을 toolchain에 통합할 수 있다.

✔️Fine-grained Build Comparison [Gradle Enterprise] - 세분화된 빌드 비교
빌드 스캔 비교는 종속성 및 버전과 같은 빌드 간의 차이점을 신속하게 강조하여 근본 원인 분석을 훨씬 빠르게 할 수 있게 한다.

✔️Track and Export History Across all Builds [Gradle Enterprise] - 모든 빌드에서 내역 추적 및 Export
CI 빌드 뿐만 아니라 로컬 개발 빌드를 포함하여 모든 빌드에 대한 주요 빌드 메트릭을 추적할 수 있다. 트랜드를 이해하고 빌드 스캔 데이터를 선택한 스토리지로 내보낼 수 있다.

Execution Options

✔️Continuous build - 지속적인 빌드
Gradle task가 연속모드(continuous mode)로 실행되면 Gradle은 task의 input 변경 사항을 자용으로 감시하고, 변경될 때 마다 task를 자동으로 실행한다. 다중 프로젝트 빌드에서도 여러 task를 지속적으로 실행가능하다.

✔️Composite builds - 복합 빌드
Composite build를 사용하면 다른 독립적인 프로젝트를 포함시킬 수 있다. 예를 들어 동시의존성을 가지는 응용 프로그램이나 라이브러리를 개발할 수 있다. 기본적으로 병렬로 빌드되며 중첩 가능하다.

✔️Task Exclusion - task 제외
실행중인 task를 제외할 수 있다. task를 제외하면 종속된 모든 task에게 다른 종속성이 없다면 함께 자동으로 제외된다.

✔️Dry Run
task를 실행하지 않고도 실제로 어떤 작업이 실행되는지 확인하려면 Run을 사용한다.

✔️Continue Execution After Failures - 실패 후 계속 실행
첫 번째 장애가 발생한다고 바로 실행이 중단되지는 않는다. 해당 task에 대한 모든 dependency이 오류 없이 완료된 경우 실행하려는 모든 task를 실행한다. 단일 빌드 실행에서 가능한 많은 오류를 발견할 수 있게되며, 마지막에 매우 우수한 오류 보고서를 제공한다.

✔️Fail Fast Test execution
Gradle에서는 테스트 실패 후에도 계속 진행이 기본값 이지만 --fail-fast 플래그를 설정하거나, 테스트 중 하나가 실패하자마자 Gradle 빌드가 실패하고 끝나도록 failFast=true를 구성할 수 있다.

✔️Sync Dependency Cache with Repository - 레포지토리와 종속성 캐시 동기화
Gradle에는 해결된 모듈(resolved modules)과 아티팩트에 대해 캐시된 모든 항목을 무시하는 --refresh-dependencies 옵션이 있다. 동적 버전이 다시 계산되고 모듈이 새로 고쳐지고 아티팩트가 다운로드된 모든 리포지토리 구성에 대해 새로운 resolve가 수행된다. 그러나 가능한 경우 Gradle은 다시 다운로드하기 전에 이전에 다운로드한 아티팩트가 유효한지 확인한다. (리포지토리에 게시된 SHA1 값을 기존 다운로드된 아티팩트의 SHA1 값과 비교해 수행된다.)

Authoring Gradle Builds

build 작성자 및 효율적으로 개발하려는 담당자에게 필요하다.

Build Logic is Testable Code

✔️Groovy DSL
이상적으로 Groovy 빌드 스크립트는 대부분 프로젝트의 일부 속성 설정(properties), 종속성 구성(configuting dependencies), task 선언(declaring task) 등을 포함한 configuration과 비슷하다. 해당 configuration은 Groovy 언어를 기반으로 한다.

✔️Kotlin DSL
Gradle의 Kotlin DSL은 기존 Groovy DSL에 대한 대안 구문을 지원한다. 이는 이를 지원하는 IDE에서 향상된 편집 환경과 우수한 컨텐츠 지원, 리팩토링, 문서화 등을 제공한다.

✔️Gradle Init Plugin
Gradle Build Init 플러그인은 다양한 유형의 새로운 Gradle 빌드 (Java 애플리케이션, Java 라이브러리, Groovy 라이브러리, Kotlin 애플리케이션 등)를 작성하거나 기존 빌드 (예 : Apache Maven 빌드)를 Gradle 빌드로 변환하는 데 사용할 수 있다.

Dependency Management

✔️Transitive Dependencies - 전이적 종속성
종속성 관리 시스템 사용의 주요 이점 중 하나는 전이 종속성을 관리하는 것이다. Gradle은 전이적 종속성을 다운로드하고 관리한다.

✔️Custom Dependency Scopes - 사용자 지정 종속성 번위
사전 정의된 종속성 범위(compile, runtime 등)에 제한되지 않아도 된다. Gradle을 사용하면 임의의 종속성 범위를 정의 할 수 있다. 예를 들어 빌드에서 모델링 할 수 있는 통합 테스트, 빌드에 필요한 toochain 프로비저닝 등이 있다.

✔️File Based Dependencies - 파일 기반 종속성
외부 저장소으로부터 모든 종속성을 사용 가능한 것은 아니다. 관리되는 종속성을 사용할 때 또는 과거의 빌드를 마이그레이션 할 때 파일 시스템 리소스에 대한 종속성을 선언해라.

✔️Custom Repository Layout
사용자 정의 레이아웃으로 리포지토리를 선언할 수 있다. 사용자 정의 레이아웃을 사용하면 거의 모든 파일 시스템 디렉토리 구조를 아티팩트 저장소로써 효과적으로 처리할 수 있다.

✔️3rd Party Dependency Cache - 타사 종속성 캐시
원격 저장소(remote repository)의 종속성은 로컬로 다운로드 및 캐시된다. 후속 빌드는 불필요한 네트워크 트래픽을 피하기 위해 캐시된 아티팩트를 사용한다.

✔️Maven and Ivy Repository Compatible
Gradle은 POM & IVY metadata 형식과 호환되며 Maven 또는 IVY 호환 저장소에서 종속성을 검색할 수 있다. IVY metadata는 사용자 정의 분석 규칙에 노출되므로 artifact branch, status 또는 기타 커스텀 metadata 정보를 필터링 할 수 있다.

✔️Native BOM support
Maven BOM 종속성이라는 플랫폼 정의가 기본적으로 지원되므로 외부 플러그인을 사용하지 않고도 Spring Boot 플랫폼 정의와 같은 항목을 가져올 수 있다.

✔️Dynamic Dependencies
resolve된 종속성 버전은 동적일 수 있다. Gradle은 Maven 스탭샷 매커니즘을 지원하지만 그보다 강력하다. 최신 릴리스, 최신 개발 버전 또는 최신 5.x 빌드에 대한 종속성을 선언할 수 있다.

✔️Dynamic Dependency Locking - 동적 종속성 잠금
동적 종속성 버전을 사용할 때 빌드가 결정론적(deterministic, 주어진 조건들을 만족하는 유일해가 존재한다는 가정하에서의 문제 접근 방법)이고 재현가능한(reproducible) 상태를 유지하도록 한다.

✔️Dynamic Dependencies Selection Rules - 동적 종속성 선택 규칙
동적 종속성이 선언 될 때 특정 버전을 선택하도록 커스텀 규칙을 정의해라. 규칙은 이름과 버전을 기반으로하지만 branch나 status같은 확장된 metadata를 기반으로 할 수 있다. 규칙은 빌드가 진행되는 환경(e.g. 로컬 또는 CI)에 따라 다를 수 있다.

✔️Dependency Version Alignment - 의존성 버전 정렬
의존성 정렬을 사용하면 논리적 그룹의 다른 모듈(e.g. Jackson module)을 동일한 버전으로 정렬할 수 있다.

✔️Version Conflict Resolution - 버전 충돌 해결
기본적으로 Gradle은 최신 요청 버전으로 충돌을 해결한다. 이 동작은 사용자 정의가 가능하다.

✔️Substitution of Compatible Libraries - 호환 라이브러리 대체
종속성 대체 규칙을 사용하여 종속성이 유사한 것으로 처리되어야 함을 식별해라. 예를 들어 log4j 및 log4j-over-slf4j이다. Gradle 충돌 해결을 사용해 둘 중 최신 버전을 선택할 수 있도록 설정해야한다. 유사한 사용 사례는 의존성 그래프에 spring-all 및 spring-core와 같은 라이브러리가 있는 상황이다. 이를 올바르게 모델링하지 않으면 응용 프로그램의 올바른 행동은 classpath의 취약한 순서를 따른다.

✔️Enhanced Metadata Resolution Support - 향상된 메타 데이터 분석 지원
Dependency metadata는 레포지토리 metadata를 다운로드 한 후에도 수정될 수 있지만, Gradle에서 resolve 버전으로 선택된 후에는 수정할 수 없다. 이를 통해 모듈을 바뀐 버전(혹은 스냅샷 버전)으로 선언하거나 커스텀 상태 scheme을 사용하는 것 등을 할 수 있는 커스텀 룰을 만들 수 있다.

✔️Replacement of external and project dependencies - 외부 의존성 및 프로젝트 의존성의 교체
프로젝트 의존성에 대한 외부 의존성을 동적으로 대체하거나, 반대로 모듈의 subset만 로컬에서 체크 아웃할 때 유용하다.

Standardizing Gradle Across Teams

✔️Self-Provisioning Build Environment - 자체 프로비저닝 빌드 환경
Gradle 래퍼를 사용하면 Gradle 빌드 환경이 자동 프로비저닝된다. 또한 프로젝트를 빌드하는데 사용해야하는 버전을 선택할 수 있다.
🔎Provisioning : 어떤 종류의 서비스든 사용자의 요구에 맞게 시스템 자체를 제공하는 것. 이 때 제공해 주는 것은 인프라 자원이나 서비스, 장비 등이 될 수 있다.
🔎Auto-Provisioning : 가상화 시스템, 유틸리티 컴퓨팅, 클라우드 컴퓨팅 환경에서 IT인프라 자원을 할당, 배치, 배포 구성하는 작업들을 자동화해주는 기능

✔️Version Controlled Build Environment Configuration
빌드 환경 구성을 위한 중요 매개변수는 프로젝트의 일부로서 버전에 저장할 수 있다. 개발자가 수동으로 이를 설정할 필요는 없다. 여기에는 사용할 Gradle 버전, 빌드를 실행하는 JVM을 위한 configuration, 빌드를 실행하기위해 사용되는 JDK이 포함된다.

✔️Custom Distributions
모든 Gradle 배포에는 빌드 환경을 사전 구성하는 커스텀 script를 넣을 수 있는 init.d 디렉토리가 있다. 이를 통해, 수행될 커스텀 룰을 적용하고 개발자를 위해 내장 설정 작업 등을 제공할 수 있다. Gradle 래퍼와 함께 이런 Custom Distribution을 쉽게 배포할 수 있다.

Software Domain Modeling

✔️Domain Object Containers
레포지토리, 소스 디렉토리, 플러그인, dependency 등 빌드를 설명하는 모든 도메인 오브젝트는 리스너를 등록 할 수 있는 반응형 컨테이너에 저장된다. 당신은 빌드에 추가하는 특정 빌드 스크립트를 완전히 제어할 수 있다. 예를 들면 추가된 항목을 늘리거나 수정하여 빌드에 실패하거나 위험한 이슈가 발생하도록 만들 수 있다. 구체적으로 당신은 빌드가 특정 플러그인을 추가하는 경우에만 추가되는 정의 종속성을 추가 할 수도 있다.

✔️Publishing Multiple Artifacts
Gradle은 다른 metadata를 사용해 프로젝트당 여러 아티팩트를 게시 할 수 있다. 다양한 Java 플랫폼에 대한 API, implementation jar, library, test-fixture 나 변형된 형태 등이 그 예이다.

✔️Advanced Task Ordering
Gradle은 작업간에 생성되는 종속성을 완전히 제어 할 뿐만 아니라 task가 서로의 output에 의존하지 않더라도 task 간의 실행 순서를 설명하는 강력한 언어 구성을 가지고 있다. 이는 shouldRunAfter와 mustRunAfter 관계로 모델링 할 수 있다.

✔️Task Dependency Inference
Gradle 오브젝트는 특정 content를 생성하는 task를 알고 있다. 예를 들어, Java 바이너리 디렉토리를 나타내는 오브젝트는 컴파일 작업이 바이너리 파일을 생성함을 알고 있다. Java 바이너리 디렉코리를 input으로 사용하는 모든 task는 자동으로 compile task에 의존하게 된다. 이를 수동으로 선언할 필요가 없으므로 빌드를 보다 쉽게 유지 관리 할 수 있다.

✔️Task Finalizers
Java의 finalizer절과 유사하게 다른 작업을 마무리하기 위한 task를 할당할 수 있다. 이 task의 실패 여부는 관계없으며 항상 다른 작업이 실행 된 후에 할당된 task는 실행된다. 이는 컨테이너나 데이터베이스에 대한 lifecycle 관리를 수행할 때 매우 유용하다.

✔️Dynamic Task Creation
때로는 어떤 동작이 매우 크거나 무한한 값의 매개변수 범위에 의존하는 task를 원할 수도 있다. 이런 task를 제공하는 훌륭한 표현 방식은 task rule이다.

✔️Fine Grained Build Event Listener - 세분화된 빌드 이벤트 리스너
Gradle을 사용하면 사용자 지정 동작을 주입하는 것, 정보를 추출하는 것, 추가적인 로깅을 추가하는 것, 다른 많은 use case를 위해 실행 lifecycle과 빌드 구성의 모든 부분에 연결할 수 있다.
🤔 Gradle allows you to hook into every part of the build configuration and execution lifecycle for injecting custom behaviour, extracting information, adding additional logging and a tons of other use cases.

✔️User Based Behavior Injection
컴퓨터에서 실행되는 모든 Gradle 빌드에 연결되는 커스텀 리스너를 Gradle user home에 넣을 수 있다. 위에서 설명한 라이프 사이클 리스너를 사용하면 빌드 경험을 개별화하려는 커스텀 동작을 추가 할 수 있다. 예를 들어, 빌드가 완료되거나 실패할 때 Gradle 알림 플러그인을 추가하고 설정하거나, 개인적으로 사용하는 특수한 저장소를 추가할 수 있다.

✔️Per Build Behavior Injection
사용자 기반 행동 주입과 마찬가지로 command line에서 빌드에 연결되는 추가 리스너를 지정할 수도 있다. 이는 CI 빌드에서 특정 동작을 수행하려는 경우 (e.g. 비표준 레포지토리를 사용하는 경우에는 실패하도록 하는 것) 매우 유용하다.

Gradle Plugin Authoring

✔️TestKit for Functional Testing
테스크 프레임워크에 관계없이 API를 통해 빌드를 프로그래밍 방식으로 실행한다. 빌드 결과 및 출력을 검사한다. 버전간 호환성을 테스트한다. IDE에서 테스트 중인 빌드를 디버깅한다.

✔️Custom Command Line Options
task API는 런타임시 특정 이름으로 해당 명령행 매개 변수를 자동으로 생성하는 property를 표시하는 메커니즘을 지원한다.

Ecosystem-specific Features

Features specific to JVM, Android, C++, Swift, Objective C, and other ecosystems.

JVM Applications

✔️Incremental Compilation for Java - Java를 위한 점진적 컴파일
소스 코드 또는 classpath 변경 여부에 관계없이, Gradle은 변경의 영향을 받는 모든 클래스를 감지하고 해당 클래스만 다시 컴파일한다.

✔️Compile Avoidance for Java
종속 프로젝트가 ABI 호환 방식으로 변경되면 (비공게 API만 변경됨) Java compile task가 최신 상태로 업데이트 된다.

✔️Built-in Groovy Support
Groovy 플러그인은 Java 플러그인을 확장하여 Groovy 프로젝트에 대한 지원을 추가한다. Groovy code, mixed Groovy, Java code, 순수 Java code까지 처리할 수 있다.

✔️Built-in Scala Support
Scala 플러그인은 Java 플러그인을 확장하여 Scala 프로젝트에 대한 지원을 추가한다. 스칼라 코드, 혼합 스칼라 및 Java 코드, 순수 Java 코드까지 처리 할 수 있다

✔️Built-in Support for JVM Code Quality Tools - JVM 코드 품질 도구에 대한 기본 지원
Gradle 배포에는 Checkstyle , CodeNarc , PMD , JaCoCo 및 기타 도구 용 플러그인이 포함되어 있다.

✔️Packaging and Distribution for JARs, WARs, and EARs
Gradle은 JVM 기반 코드를 공통 아카이브 파일로 패키지하는 도구와 함께 기본 제공된니다.

✔️Publishing to Maven Repositories
Bintray 또는 Maven Central과 같은 Maven 저장소에 아티팩트를 게시할 수 있다.

✔️Publishing to Ivy Repositories
사용자가 직접 커스텀 가능한 디렉토리 레이아웃을 사용하여 아티팩트를 Ivy 레파지토리에 게시할 수 있다.

✔️Ant Integration - Ant 통합
default, 선택적, 사용자 정의 Ant task를 깊게 통합할 수 있다. 런타임 시에 Ant 빌드를 import하고 Gradle 작업에 따라 Ant 대상을 부분적으로 바꿀 수 있다.