Maven과 gradle

여덟번째로 포스팅하게 될 내용은 Maven과 Gradle입니다.

 

[ 빌드 관리 도구란? ]

• 프로젝트에서 필요한, xml, jar 파일들을 자동으로 인식하여 빌드해주는 도구
• 소스코드를 컴파일, 테스트, 정적분석 등을 하여 실행가능한 앱으로 빌드해줌
• 프로젝트 정보 관리, 테스트 빌드, 배포 등의 작업을 진행
• 외부 라이브러리를 참조하여 자동으로 다운로드 및 업데이트의 관리를 해줌
• Ant, Maven, Gradle 과 같은 것이 있음

[ 빌드 관리 도구 역사 ]

1세대 Make

• 빌드 개념을 확립
• Unix 계열 OS에서 사용

 

2세대 Ant

• 범용성을 높임(크로스 플랫폼 대응)
• Make를 java에 적용하려다보니 문제, 보완하기 위해 탄생
• Java + XML 도입

 

3세대 Maven

• 작성 효율을 높임
• 라이프 사이클 도입
• 빌드 생명주기와 프로젝트 객체모델(POM)개념을 도입 
• Ant의 문제점인 장황한 빌드스크립트 문제를 해결

 

4세대 Gradle

• 스크립트 언어로 유연성을 증가
• Maven보다 빠름
• 기존 Maven, Ivy 등 다른 빌드도구와 호환 가능

 

[ Maven ]

• 자바의 대표적인 관리 도구였던 Ant를 대체하기 위해 개발됨
• 프로젝트를 진행할 때, 단순히 자신이 작성한 코드만으로 개발하는 것이 아니라 많은 라이브러리들을 활용해서 개발
• 이 때 사용되는 라이브러리들의 수가 수십개가 훌쩍 넘어버리는 일이 발생해 이 많은 라이브러리들을 관리하는 것이 힘들어지는 경우가 종종 발생하곤 한다. Maven은 이러한 문제를 해결해 줄수 있는 도구
• Maven은 내가 사용할 라이브러리 뿐만 아니라 해당 라이브러리가 작동하는데 필요한 다른 라이브러리들까지 관리하여 네트워크를 통해 자동으로 다운 받음
• Maven은 프로젝트의 전체적인 라이프사이클을 관리하는 도구이며, 많은 편리함과 이점이 있어 널리 사용
• XML 기반의 빌드 스크립트이고,  라이프 사이클을 사용
• 프로젝트의 외부 라이브러리를 쉽게 참조할 수 있게 pon.xml 파일로 명시하여 관리
• 기존에는 Ant가 많이 사용되었지만 Maven이 Ant를 넘어서 더 많은 개발자들이 사용

 

[ Maven의 Lifecycle ]

Maven 에서는 미리 정의하고 있는 빌드 순서가 있으며 이 순서를 라이프사이클이라고 한다.
라이프 사이클의 각 빌드 단계를 phase 라고 하고, 각각의 phase는 의존관계를 가지고 있어 해당 phase가
수행되려면 이전 단계의 phase가 모두 수행되어야 한다. 
Maven에서 clean, default, site의 크게 세가지 라이프사이클을 제공한다.

 

phase: phase 자페는 명령이 아닌 논리적인 빌드 단계이고 실제로는 phase에 연결된 piug-in이 있다

           이 plug-in이 수행할 수 있는 명령들이 실행되는것이다.

           위와 같이 phase에 연결되어있는 plug-in이 수행하는 명령을 goal이라고 한다.

phase는 빌드 순서에 맞게 지정이 돼있으므로 바꿀수도 바꿀 필요도 없다. 대신 phase단계에 수행할 명령을 추가하거나 삭제하고 싶으면 phase에 연결되어있는 goal을 수정함으로 Maven을 유연하게 확장시킬수 있다.

 

 

자주 사용되는 라이프사이클

• Clean Lifecycle
  • Clean : 이전 빌드에서 생성된 파일들을 삭제하는 단계

 

• Default Lifecycle
  • Validate : 프로젝트가 올바른지 확인하고 필요한 모든 정보를 사용할 수 있는지 확인하는 단계
  • Compile : 프로젝트의 소스코드를 컴파일 하는 단계
  • Test : 유닛(단위) 테스트를 수행하는 단계
    • 테스트 실패시 빌드 실패로 처리하고 스킵 가능
  • Package : 실제 컴파일된 소스코드와 리소스들을 jar등의 배포를 위한 패키지로 만드는 단계
  • Verify : 통합테스트 결과에 대한 검사를 실행하여 품질 기준을 충족하는지 확인하는 단계
  • Install : 패키지를 로컬 저장소에 설치하는 단계
  • Deploy : 만들어진 Package를 원격 저장소에 release하는 단계

 

• Site Lifecycle
  • Site : 프로젝트 문서를 생성하는 단계

 

[ POM - Project Object Model ]

pom은 Project Object Model 의 약자로 이름 그대로 Project Object Model의 정보를 담고있는 파일

• 프로젝트 정보 : 프로젝트의 이름, 개발자 목록, 라이센스 등
• 빌드 설정 : 소스, 리소스, 라이프 사이클별 실행한 플러그인(goal)등 빌드와 관련된 설정
• 빌드 환경 : 사용자 환경 별로 달라질 수 있는 프로파일 정보
• POM연관 정보 : 의존 프로젝트(모듈), 상위 프로젝트, 포함하고 있는 하위 모듈 등

 

POM은 pom.xml파일을 말하며 Maven의 기능을 이용하기 위해 POM이 사용

 

[ Gradle ]

• Gradle이란 Groovy 기반의 오픈소스 빌드 자동화 툴이다.
• 안드로이드 앱을 만들때 필요한 공식 빌드시스템이기도 하며 JAVA, C/C++, Python 등을 지원한다.
• 빌드툴인 Ant Builder와 그루비 스크립트를 기반으로 구축되어 기존 Ant의 역할과 배포 스크립트의 기능을 모두 사용가능하다.
• 별도의 빌드스크립트를 통하여 사용할 어플리케이션 버전, 라이브러리등의 항목을 설정 할 수 있다.
• 스크립트 언어로 구성되어 있어, XML과 달리 변수선언, if, else, for등의 로직이 구현가능하여 간결한 정의 가능하다.
• 프로젝트를 설정 주입 방식으로 정의해서 Maven의 상속 구조보다 재사용에 용이하다.
• 간결함, 속도, 유연성, 확장성,과 공식 홈페이지에 문서화된 것이 많은 장점이 있다.

 

직관적인 코드와 자동완성

Maven과 같이 xml같은 마크업 언어를 사용하는 것이 아닌, Groovy나 Kotlin으로 짤 수 있어서 매우 가독성이 뛰어나다. 몇년 전까지 Groovy만 지원해서 자동완성과 코드 찾기가 안 되었었지만, 최근에 Kotlin DSL을 이용해 사용할 수 있게 되어서 가독성이 매우 올라갔다.

 

다양한 Repository의 사용 가능

Maven Repository, JCenter 외 커스텀 파일 저장공간 등 다양한 저장공간을 사용할 수 있고, 단순히 Repository에 대한 정의만 해주면 된다.

 

[ Gradle 사용 ]

build.gradle

build.gradle 파일은 빌드 스크립트라고 하며 엄밀히 말하면 빌드 구성 스크립트라고 한다.
의존성이나 플러그인 설정 등과 같은 빌드에 필요한 설정을 하게 된다.

 

Task

Gradle의 실행 작업 단위가 테스크(Task)이다. Gradle은 기본적으로 테스크를 수행하며 테스크를 구성하고 작성하는 것이 빌드 스크립트를 작성하는 과정이다.

 

Gradle wrapper

사용자가 Gradle을 설치하지 않았어도 Gradle tasks를 실행할 수 있도록 도운다.
프로젝트 생성자와 동일한 버전의 Gradle을 사용할 수 있게 한다.

 

메소드

• repositories 메소드
  • repositories 메소드는 저장소 설정을 담당
• ext 메소드
  • ext 메소드는 그 인자를 buildScript 에서 전역변수로 사용하기 위해 사용
• dependencies 메소드
  • 의존성 라이브러리를 추가할 때 사용
    • implementation
      • 의존 라이브러리 수정시 본 모듈까지만 재빌드
    • api
      • 의존 라이브러리 수정시 본 모듈을 의존하는 모듈들을 전부 재빌드
    • compileOnly
      • compile 시에만 빌드하고 빌드 결과물에는 포함하지 않음
    • testImplementation
      • 테스트 코드를 수행할 때만 적용
    • annotationProcessor
      • annotation processor 명시
      • (ex. annotationProcessor 'org.projectlombok:lombok')

 

[ Gradle과 Maven 차이 ]

1. Build라는 동적인 요소를 XML로 정의하기에 너무 어렵다
   1. 설정 내용이 길어지고 가독성이 떨어진다.
   2. 의존관계가 복잡한 프로젝트 설정하기에는 너무 부적절하다.
   3. 특정 설정을 모듈에서 공유하기 위해서는 부모 프로젝트를 생성하여 상속하게 해야해서 상속의 단점이 생긴다.
2. Gradle에 비해 Maven이 성능이 떨어짐
3. Maven에 비해 Gradle이 대규모 프로젝트에서의 성능이 좋음
4. Maven : pom.xml , Gradle : build.gradle
5. Gradle은 설치 없이 사용 가능

 

현재 개발자들이 Gradle의 사용량보다 Maven의 사용량이 높은 이유는 익숙함 때문이다.

Gradle은 Maven의 거의 모든 부분 앞서나가지만 Maven과 익숙해진 XML을 버리고 Gradle과 Groovy문법을 배우는 것은 효율적이지 않다. 

그렇지만 Gradle은 빌드타임 비용문제와 같은 여러가지 문제들을 고려했을때 언젠가는 사용하게 될 것이다.