Maven vs Gradle
스프링 기반의 프로젝트를 시작하면서 Maven을 처음 접했다.
Ant를 사용한적도 없었고 의존성 관리와 빌드 스크립트에 대한 지식도 없었기에 이런게 있나보다 하고 사용했었다.
Maven 책을 한권 보고나서야 프로젝트 구성, 빌드툴이 무었인지 이해할 수 있었고, 편리한 의존성 관리에 감사하며 부족함을 느끼지 못했다.
하지만 프로젝트의 단위가 커지면서 빌드와 테스트에 소요되는 시간이 길어졌고,
여러 모듈에서 설정을 상속받기 시작하면서 Gradle이라는 녀석이 계속 눈에 뛰었다.
Gradle이 Maven의 단점을 보완해주고 사용해본 사람들이 좋다고들 하니 Maven이랑 비교해서 얼마나 좋은지 알아보려 한다.
Maven
Apache의 이름 아래 2004년 출시
Ant를 사용하던 개발자들의 불편함을 해소 + 부가기능 추가
- 빌드를 쉽게 (Making the build process easy)
- pom.xml을 이용한 정형화된 빌드 시스템 (Providing a uniform build system)
- 뛰어난 프로젝트 정보 제공 (Providing quality project information_
- Change log document created directly from source control
- Cross referenced sources
- Mailing lists
- Dependency list
- Unit test reports including coverage
- 개발 가이드 라인 제공 (Providing guidelines for best practices development)
- Keeping your test source code in a separate, but parallel source tree
- Using test case naming conventions to locate and execute tests
- Have test cases setup their environment and don’t rely on customizing the build for test preparation.
- 새로운 기능을 쉽게 설치할 수 있고 업데이트할 수 있음 (Allowing transparent migration to new features)
Gradle
Ant와 Maven의 장점을 모아모아 2012년 출시
Android OS의 빌드 도구로 채택 됨
- Ant처럼 유연한 범용 빌드 도구 (A very flexible general purpose build tool like Ant.)
- Maven을 사용할 수 있는 변환 가능 컨벤션 프레임 워크 (Switchable, build-by-convention frameworks a la Maven. But we never lock you in!)
- 멀티 프로젝트에 사용하기 좋음 (Very powerful support for multi-project builds.)
- Apache Ivy에 기반한 강력한 의존성 관리 (Very powerful dependency management (based on Apache Ivy))
- Maven과 Ivy 레파지토리 완전 지원 (Full support for your existing Maven or Ivy repository infrastructure.)
- 원격 저장소나, pom, ivy 파일 없이 연결되는 의존성 관리 지원
(Support for transitive dependency management without the need for remote repositories or pom.xml and ivy.xml files.) - 그루비 문법 사용 (Groovy build scripts.)
- 빌드를 설명하는 풍부한 도메인 모델 (A rich domain model for describing your build.)
Maven VS Gradle
Maven에는 gradle과 비교 문서가 없지만, gradle에는 비교문서가 존재. (비교에 자신있는 모습 ..ㅋ)
Gradle이 시기적으로 늦게 나온만큼 사용성, 성능 등 비교적 뛰어난 스펙을 가지고있다.
- Build라는 동적인 요소를 XML로 정의하기에는 어려운 부분이 많다.
- 설정 내용이 길어지고 가독성 떨어짐
- 의존관계가 복잡한 프로젝트 설정하기에 부적절
- 상속구조를 이용한 멀티 모듈 구현
- 특정 설정을 소수의 모듈에서 공유하기 위해서는 부모 프로젝트를 생성하여 상속하게 해야 함 (상속의 단점 생김)
- Gradle은 Groovy를 사용하기 때문에, 동적인 빌드는 Groovy 스크립트로 플러그인을 호출하거나 직접 코드를 짜면 된다.
- Configuration Injection 방식을 사용해서 공통 모듈을 상속해서 사용하는 단점을 커버했다.
- 설정 주입 시 프로젝트의 조건을 체크할 수 있어서 프로젝트별로 주입되는 설정을 다르게 할 수 있다.
Gradle vs Maven: Performance Comparison
- 600명의 엔지니어가 1년동안 1분걸리는 빌드를 매주 42번 빌드를 진행할 때 들어가는 비용은
600 engineers * $1.42/minutes * 42 builds/week * 44 work weeks/year = $1,600,000/year
이때 빌드 속도가 90% 빨라진다면? - Gradle은 메이븐 보다 최대 100배 빠르다.
- 어떻게?
- the Gradle Daemon is a long-lived process that keeps build information “hot” in memory
- incremental task inputs and outputs for various types of tasks makes it unnecessary to run clean ever again
- incremental compilation analyzes the dependencies between your sources and classes and recompiles only those which are affected by changes
- the build cache fetches results from a cache when switching branches or running a clean build and the same output has already been produced somewhere else in the organization.
- Gradle’s smart classpath analyzer avoids unnecessary compilation when the binary interface of a library hasn’t changed
- better modelling of dependencies using the Java Library plugin reduces the size of the compile classpath which has a large, positive impact on performance
예제
스프링부트를 이용하여 같은 기능과 라이브러리 의존성을 가지는 Maven, Gradle 프로젝트를 생성해 보았다. (Java 1.8, Spring Boot 1.5.4)
- 스크립트 길이와 가독성 면에서 Gradle(groovy)이 앞선다.
- 빌드와 테스트 실행 결과 Gradle이 더 빠르다. (Gradle이 캐시를 사용하기 때문에 테스트 반복 시 차이가 더 커진다.)
- 의존성이 늘어날 수록 성능과 스크립트 품질의 차이가 심해질 것이다.
Maven
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.example</groupId>
<artifactId>demo-maven</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>jar</packaging>
<name>demo-maven</name>
<description>Demo project for Spring Boot</description>
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>1.5.4.RELEASE</version>
<relativePath/> <!-- lookup parent from repository -->
</parent>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
<java.version>1.8</java.version>
</properties>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
</plugins>
</build>
</project>
Gradle
buildscript {
ext {
springBootVersion = '1.5.4.RELEASE'
}
repositories {
mavenCentral()
}
dependencies {
classpath("org.springframework.boot:spring-boot-gradle-plugin:${springBootVersion}")
}
}
apply plugin: 'java'
apply plugin: 'idea'
apply plugin: 'org.springframework.boot'
version = '0.0.1-SNAPSHOT'
sourceCompatibility = 1.8
repositories {
mavenCentral()
}
dependencies {
compile('org.springframework.boot:spring-boot-starter')
testCompile('org.springframework.boot:spring-boot-starter-test')
}
결론
지금 시점에서 Gradle을 사용하지 않을 이유는 '익숙함' 뿐인 것 같다.
Gradle이 출시되었을 때에는 Maven이 지원하는 Scope를 지원하지 않았고 성능면에서도 앞설것이 없었다.
Ant의 유연한 구조적 장점과 Maven의 편리한 의존성 관리 기능을 합쳐놓은 것만으로도 많은 인기를 얻었던 Gradle은 버전이 올라가며 성능이라는 장점까지 더해지면서 대세가 되었다.
물론 그동안 사용해왔던 Maven과 이제는 익숙해진 XML을 버리고 Gradle과 Groovy문법을 배우는 것은 적지않은 비용이 든다.
특히 협업을 하는 경우, 프로젝트 구성과 빌드만을 위해 모든 팀원이 Groovy 문법을 익여야 한다는 사실은 Gradle를 사용하는데 큰 걸림돌이 된다.
실제로 여전히 Maven의 사용률은 Gradle을 앞서고 있으며 구글 트랜드 지수도 Maven이 Gradle을 앞선다.
협업과 러닝커브를 고려하여 여전이 Maven를 사용하는 팀이 많고 부족함 없이 잘 사용하고 있지만,
앞서 요약했듯 프로젝트의 빌드타임이 비용문제로 이어질 경우 Gradle을 사용해야 할 것 같다.
리드미컬?하게 테스트를 진행하고 민첩한? 지속적 배포를 생각하고 있다면 새로움 배움이 필요하더라도 Gradle을 사용해보자. 아자.
출처
'SPRING' 카테고리의 다른 글
| Spring Batch 와 Jekins 를 이용하여 간단한 배치 환경 구성하기 (1376) | 2019.02.13 |
|---|---|
| Spring batch의 transaction manager bean 중복 문제 해결하기 (feat Spring boot 2.1) (1358) | 2019.02.12 |
| Spring long polling(Async Servlet) 이용하여 응답지연 서버 만들기 (451) | 2015.11.22 |
