본문 바로가기

PROGRAMMING/MAVEN

MAVEN(메이븐)의 정의

 

MAVEN(메이븐)이란 도대체 무엇인가?

 

메이븐은 라이브러리에 대한 의존 관계를 관리하는 기능 외에도 프로젝트 빌드에 필요한 기능을 지원하는 툴이라고 할 수 있다.

 

maven 공식 사이트(http://maven.apache.org)의 가이드에 따르면 이렇게 나와 있다.

 

At first glance Maven can appear to be many things, but in a nutshell Maven is an attempt to apply patterns to a project's build infrastructure in order to promote comprehension and productivity by providing a clear path in the use of best practices. Maven is essentially a project management and comprehension tool and as such provides a way to help with managing:

  • Builds(빌드)
  • Documentation(문서화)
  • Reporting(리포팅)
  • Dependencies(의존 관계)
  • SCMs(소스 코드 관리)
  • Releases(릴리즈)
  • Distribution(배포)

If you want more background information on Maven you can check out The Philosophy of Maven and The History of Maven. Now let's move on to how you, the user, can benefit from using Maven.

 

▶ 이 말을 내가 최대한 해석해본다면 '메이븐은 개발자의 이해와 생산성을 증진시키기 위해 가장 좋은 사례를 바탕으로 그 사례 사용에 대한 방법을 제공해주는 패턴을 빌드 기초 틀(infrastructure)에 적용시키는 것'이다.

 

문득 든 생각은 마치 framework에서 개발자들이 개발을 하게 되면 정형화 된 틀 안에서 비슷한 패턴으로 개발하듯이 메이븐 역시 정형화된 틀 안에서 빌드나 프로젝트 관리를 진행하는 것이 아닌가 생각이 든다. (핵심은 틀!?)

 

 

그렇다면 흔히 사용되던 ANT(앤트)와 MAVEN(메이븐)의 차이는 무엇인가?

 

* ANT(앤트)란?

: 환경에 구애받지 않고 간단히 Java 소스를 컴파일할 수 있는 빌드 툴이다. ANT는 마치 UNIX의 make와 비슷한 기능을 하는데 make와는 다르다. shell 기반의 명령어를 사용하는 대신 자바 클래스를 사용해 확장하고, shell 명령어를 쓰는 대신 XML 기반의 설정파일을 사용한다.

 

 

 ANT(앤트)

MAVEN(메이븐)

 공통점

 코드 빌드와 배포를 주로 사용하는 소스 관리 툴

 차이점

 - 일반적인 프로젝트 디렉토리 구조나  기본 행동같은 정형화된 규약이 없다. 소스를 어디서 찾고 산출물을 어디다 둬야하는지 정확히 앤트에 명령해야 한다. 시간이 지나면서 정형화되지 않은 규약이 드러났지만 제품에서 정리되지 않았다.

 

 - 앤트는 절차지향적이다. 정확히 무엇을 해야 하고 언제 해야하는지 앤트에 명령해야 한다. 컴파일하고, 복사하고 그리고 나서 압축하라고 명령해야 한다.

 

 - 앤트는 라이프싸이클을 가지지 않는다. 골과 골에 대한 의존성을 정의해야 한다. 직접 각 골에 대한 일의 순서를 정의해야 한다.

 

  - 메이븐은 규약이 있다. 개발자들이 규약을 따르기 때문에 메이븐은 소스 코드가 어디에 있는지 안다. 메이븐의 컴파일러 플러그인은 target/classes에 바이트코드를 넣고 taget에서 JAR 파일을 만든다.

 

 - 메이븐은 서술적이다. pom.xml을 만들고 소스를 디폴트 디렉토리에 넣는 것이 개발자들이 하는 전부이다. 나머지는 메이븐이 알아서 한다.

 

 - 메이븐은 당신이 'mvn install'을 실행했을 때 발동하는 라이프싸이클을 가지고 있다. 이 명령은 메이븐에게 phase 라이프싸이클 설치에 도달할 때까지 일련의 순서를 갖고 있는 라이프싸이클 명령들을 실행하라고 하는 것이다. 라이프싸이클의 부작용으로써 컴파이이나 JAR파일을 만드는 것 같은 수많은 기본 플러그인 goal들이 실행된다는 것이다.

 

http://books.sonatype.com/mvnref-book/reference/installation-sect-compare-ant-maven.html

 

앤트에는 장단점이 있어 각각 상황에 따라 적합한 것을 따르면 된다.

 

앤트는 자유도가 높아 빌드 환경이 예외적인 경우에도 유연하게 대처할 수 있고 학습 비용도 메이븐에 비하여 낮다. 하지만 정해진 형식이 없어 프로젝트를 진행할 때마다 작업을 반복해야 한다는 불편함이 있다.

 

메이븐은 프로젝트 구조와 빌드 단계가 정형화되어 있다. 자유도는 떨어지지만 메이븐을 기반으로 하는 프로젝트는 같은 디렉토리 구조와 빌드 프로세스를 갖게 된다. 따라서 메이븐에 대한 경험이 있다면 메뉴얼이나 다른 개발자 도움 없이 메이븐 기반 프로젝트를 빌드하고 소스 코드를 분석할 수 있다.

(자바 세상의 빌드를 이끄는 메이븐 p.23)

 

 

여기서 자유도가 높다는 말은 프로젝트 관점에서 봤을 때, 복잡하지 않은 별개의 프로젝트의 경우에는 라이브러리를 좀 더 추가하거나 삭제하는 등 setting에 대해 좀 더 정해지지 않은 틀에서 자유롭게 할 수 있는 것을 말한다.

 

 

Maven or Ant?(http://java.dzone.com/news/maven-or-ant) 라는 외국 글에 따르면..

 

MAVEN이 좋은 상황 :

1) 당신이 많은 창의적인 개발자들과 일하고 있을 때. tool의 지원 없이 윤곽이 분명히 나타난 프로젝트 구조 등을 설립하기 힘들 것이다.

(You are working with many "creative" developers. It will be hard to establish a defined project structure etc. without tool support.)

 

2) 같은 때에 개발자들이 그들의 IDE, IntelliJ, NetBeans 그리고 Eclipse같은 각자의 tool에 대해 독실할 때.(개발 툴에 따라 디렉토리 구조가 모두 다른데 메이븐을 사용하면 비슷한 구조로 사용할 수 있다.)

(The developers are religious about their IDE and are using IntelliJ, NetBeans and Eclipse at the same time.)

 

3) 당신이 제품과 같은 어플리케이션을 구축하고 있다. 당신은 그들의 의존성과 다른 버전과 지점을 관리해야 할 것이다.

(You are building a product-like application. You will have to manage different versions and branches with their dependencies.)

 

4) 독립적인 모듈에서 작업하던 몇몇의 팀으로 이루어져 작업을 한다. 이 모듈은 규칙적으로 응용 프로그램으로 구성되어야 한다.

(You project consists of several teams which work on dependent modules. These modules have to be composed to the application regularly)

 

5) checkstyle, pmd, 프로젝트 웹사이트 생성 등을 사용하려 계획중이다. 메이븐과 함께라면 쉽다.

(You plan to use checkstyle, pmd, generate a project website etc. It's easy with Maven)

 

ANT가 좋은 상황 :

1) 몇 주 혹은 몇 달 안에 빠르게 개발되어야 하는 Situational Software

("Situational Software" which has to be developed quickly(in a few weeks / months).)

 

2) 최신 라이브러리로 작업해야 하는 외부 의존성이 있는 프로젝트. 이런 프로젝트는 더 세세한 의존성 관리가 필요 없다.

(Projects with external dependencies which are working with "cutting edge" libraries. There is no need for finer grained dependency management)

 

3) NetBeans 프로젝트 :-) NetBeans 프로젝트는 Hudson에 완벽하게 일할 수 있는 미리 정의된 앤트 스크립트가 딸려 있다. svn 안에 모든 것을 체크하고 Hudson에 체크하도록 하기만 해라.

(* Hudson : http://hudson.dev.java.net ←바 포럼 사이트인듯..! )

(NetBeans projects :-) They come with predefined Ant scripts which even work perfectly with Hudson. Just check everything into svn and let hudson check it out..)

 

4) 메이븐 규약에 잘 맞지 않는 물려받은 프로젝트. 메이븐 규약을 어기면 귀찮은 상황이 되어버린다.

(Legacy projects which do not fit the Maven conventions very well. Violating Maven conventions may become a hassle)

 

5) 모듈화를 위한 분명한 요구사항이 없는 프로젝트. 효율적으로 활용할 수 있는 산출물은 조금 있는 압축파일로만 구성이 될 것이다.

(Projects without explicit requirements for modularization. The deployable output will consist of only a few archives.)

 

 

MAVEN과 ANT 둘 모두 훌륭한 프로젝트 관리 툴이지만 점점 MAVEN으로 이동하는 추세!

점점 프로젝트가 이리 얽히고 저리 얽혀 복잡해지고, 그런 복잡한 환경에서 반복적으로 새로운 프로젝트가 생기면서 계속 setting을 해주기엔 너무 번거로운 작업이기에

MAVEN으로 architype을 만들어 쉽게 초기 setting이 가능한 것이 MAVEN의 큰 장점이 아닐까? 또한 라이브러리도 수동으로 일일히 저장해주고 path 저장해주는 것이 아닌 버전만 잘 적어준다면 최신 라이브러리도 제때제때 사용할 수 있다는 점!?

 

책을 다시 한번 읽고 좀 더 추가해 봐야 겠다.

'PROGRAMMING > MAVEN' 카테고리의 다른 글

MAVEN - plugin, phase, goal, LifeCycle  (2) 2014.01.07