'maven'에 해당되는 글 2건

  1. 2014.04.15 Maven에 대해 알아보자 #2
  2. 2014.03.17 Maven에 대해 알아보자 #1

오늘은 저번포스팅에 이어  Maven 에 대해 알아보겠다.

이 내용은  O'Reilly Media - Maven: The Definitive Guide를 번역한 내용을 토대로 한다.


Maven과 Ant 중 어떤 것이 더 나은가는 논쟁거리가 되고 있기 때문에 이 둘을 비교하는 것은 조심스럽다.

하지만  우리는 대부분의 조직들이 Maven과 Ant 중 어떤 것을 사용할지 의사결정을 해야한다는 사실을 인지하고 있기 때문에 이 도구들에 대해 비교하고 대조할 것이다.

Ant는 빌드 프로세스로서 뛰어나며 target과 dependency를 이용한 모델링된 빌드 시스템이다. 각각의 target은 XML에 집합으로 구성되며 "jar" 작업 뿐만이 아니라 "copy" 작업과  "javac" 작업이 있다. 여러분이 Ant를 사용할 때는, 결과물을 컴파일하고 패키징하는데 특정 명령들을 사용할 수 있다. 

예제 1-1의  build.xml 파일을 살펴보자

예제 1-1. 간단한 Ant build.xml 파일

<project name="my-project" default="dist" basedir=".">

    <description>

        simple example build file

    </description>

  <!-- set global properties for this build -->

  <property name="src" location="src/main/java"/>

  <property name="build" location="target/classes"/>

  <property name="dist"  location="target"/>


  <target name="init">

    <!-- Create the time stamp -->

    <tstamp/>

    <!-- Create the build directory structure used by compile -->

    <mkdir dir="${build}"/>

  </target>


  <target name="compile" depends="init"

        description="compile the source " >

    <!-- Compile the java code from ${src} into ${build} -->

    <javac srcdir="${src}" destdir="${build}"/>

  </target>


  <target name="dist" depends="compile"

        description="generate the distribution" >

    <!-- Create the distribution directory -->

    <mkdir dir="${dist}/lib"/>


    <!-- Put everything in ${build} into the MyProject-${DSTAMP}.jar file -->

    <jar jarfile="${dist}/lib/MyProject-${DSTAMP}.jar" basedir="${build}"/>

  </target>


  <target name="clean"

        description="clean up" >

    <!-- Delete the ${build} and ${dist} directory trees -->

    <delete dir="${build}"/>

    <delete dir="${dist}"/>

  </target>

</project>

위의 간단한 Ant 예제를 보면, Ant에게 정확하게 무엇을 하고있는지 말해주는 것을 볼 수 있다. 위의 소스코드 중 파란 부분을 보면 "javac" 작업을 포함하는 compile goal이 있는데, 이것이  "src/main/java" 디렉토리에서 "target/classes" 디렉토리로 소스를 컴파일한다는 것을 볼수 있다. 

Ant에게 소스가 어디에 있는지, 결과 바이트 코드가 어디에 저장되기를 원하는지, 그리고 이 모든 것이 JAR 파일에 어떻게 패키지되어야 하는지를 정확히 말해줘야 한다.

최근 Ant를 덜 절차적이도록 도와주는 개발 도구가 생겼지만, 그래도 Ant를 사용한 개발자의 경험에 보면 XML로 쓰여진 절차 언어를 코딩하는데 있다

위의 Ant 예제와 Maven 예제를 비교해보자. 

Maven에서는 자바 소스에서 JAR 파일을 생성하기 위해 해야 할 일 은 간단하게 pom.xml을 만들고, ${basedir}/src/main/java 에 소스 코드를 위치시키고, 그 다음 command line에서  mvn install 을 실행하면 된다. 

위의 설명했던 간단한 Ant 파일(예제 1-1) 과 동일한 결과를 보여주는 Maven의 pom.xml(예제 1-2)이 아래에 나와있다.


예제 1-2. Maven의 pom.xml

<project>

  <modelVersion>4.0.0</modelVersion>

  <groupId>org.sonatype.mavenbook</groupId>

  <artifactId>my-project</artifactId>

  <version>1.0</version>

</project>


이것이 pom.xml에서 필요한 모든 것이다. 

command line에서 mvn install을 실행하기만 하면 리소스를 처리하고, 소스를 컴파일하고, 단위 테스트를 실행하고, JAR를 만들고, 다른 프로젝트에서 재사용하기 위한 로컬 레파지토리에 JAR 파일을 설치한다. 

수정없이 mvn site를 실행한면  Javadoc에 대한 링크와 소스 코드에 대한 몇몇 보고서를 포함하는 target/site 에 index.html을 발견할 수 있을 것이다.

인정하건데 위의 예제는 소스 코드와 간단한 JAR를 만드는 아주 간단한 예제 프로젝트이다.

Maven 규칙을 따르고 어떠한 의존관계나 변경이 필요하지 않은 프로젝트이다. 만일 변경하기를 원한다면 pom.xml은 크기가 커지게 되며, 수많은 plugin 설정과 의존관계 선언이 포함된 매우 복잡한 여러 메이븐 POM들을 볼 수 있을 것이다. 

하지만 프로젝트의 POM 파일들이 더 상당해 지더라도  Ant를 사용한 유사한 규모의 프로젝트의 빌드 파일과는 전체적으로 완전히 다른 종류의 정보를 가지고 있다. 

Maven POM은 "이것은 JAR 프로젝트이다", "그 소스 코드는 src/main/java 에 있다"와 같은 선언들을 포함한다. 

반면 Ant 빌드 파일은 "이것은 프로젝트이다", "그 소스는 src/main/java 에 있다", "이 디렉토리에 대해 javac를 실행하라", "target/classes 에 결과물들을 위치시켜라", "...에서 JAR를 만들어라" 등과 같은 명확한 명령을 포함한다. 

Ant는 절차에 대해서 명확하게 해야하는 반면에,  Maven에는 소스 코드가 어디에 있는지 그리고 어떻게 처리되어야하는지를 알고있는 "built-in"된 무언가가 존재한다.

이 예제에서 Ant와 Maven의 차이는 다음과 같다.

  • Apache Ant
1. Ant는 공통 프로젝트 디렉토리 구조 또는 기본 행위와 같은 형식적인 규칙을 가지지 않는다. 그래서 Ant한테는 소스코드를 찾는 위치와 결과물을 넣는 위치를 정확하게 알려주어야 한다. 형식적인 규칙들이 시간이 지남에 따라 나타나기는 하였지만, 이러한 규칙들은 프로젝트에서 코딩되지 않았다.

2.Ant는 절차적이다. 그래서 Ant에게 무엇을 할 것인지 언제 할 것인지를 정확하게 알려줘야 한다. 또한 컴파일하고, 그 다음에 복사하고, 그 다음에 압축하라고 알려줘야 한다.

3.Ant는 생명주기를 가지지 않는다. 그래서 목표들과 목표에 대한 의존관계를 정의해야 한다. 또 일일이 각 목표에 대한 일련의 작업을 추가해줘야 한다.
  • Apache Maven

1.Maven은 규칙을 갖는다. 규칙을 따랐기 때문에 소스 코드가 어디에 있는지를 알고, Maven의 컴파일러 플러그인은  target/classes 에 바이트코드를 위치시키고, target에 JAR 파일을 만들었다.

2.Maven은 선언적이다. 간단하게  pom.xml 파일을 만들고 기본 디렉토리에 소스를 위치시켰을 뿐이다. 그리고서 나서 Maven이 나머지를 알아서 수행했다.

3.Maven은 생명주기를 갖는데, mvn install을 실행했을 때 적용된다. 이 명령은  생명주기에 도달할 때까지 일련의 절차를 실행하라고 Maven에게 전달해 준다. 생명주기를 통한 이러한 과정의 부수 효과로써 Maven은 컴파일과 JAR 생성과 같은 일을 수행하는 많은 기본 플러그인 goal을 실행했다.

Ant 라이브러리와 Ivy 같은 기술 지원없이 (이러한 기술을 지원된다고 하더라도) , Ant는 절차적인 빌드라는 것에 대한 느낌을 지울수 없다. Maven의 규칙을 고수하고 있는 Maven POM들은 Ant에 비해 상당히 적은 양의 XML을 가진다. Maven의 또다른 이점은 넓게 공유된 Maven 플러그인에 의존한다는 것이다. 모든 사람은 단위 테스팅을 위해 Maven의 Surefire 플러그인을 사용하며, 누군가가 새로운 단위 테스팅 프레임워크가 지원되도록 추가한다면 단지 프로젝트의 POM에 있는 특정 Maven 플러그인의 버전을 높임으로써 빌드에 새로운 기능을 추가할 수 있다.

표 1-1

Maven

ANT

프로젝트에 대한 기술

각 프로젝트마다 빌드 스크립트 개발

기 구현된 goal(taget) 수행

프로젝트 특화된 target 수행

프로젝트 전체 정보를 정의

빌드 프로세스만 정의

빌드 생명주기, 표준화된 디렉토리 레이아웃

매우 복잡한 빌드 스크립트

재사용 가능한 플러그인, 저장소

스크립트가 재사용 가능하지 않음

매우 빠른 속도로 발전하고 있음

발전속도가 느려짐

그러니까 Maven이냐  Ant냐를 결정하는 것은 이분법적인 것이 아니며, Ant는 여전히 복잡한 빌드에서 사용되고 있다. 만일 현재 빌드가 자주 바뀌는 절차가 있다거나, Maven 표준에 적합하지 않은 특정 방식으로 특정 프로세스를 완료하기 위해 Ant 스크립트를 작성했다면, Maven에서 이러한 스크립트를 여전히 사용할 수 있다. Ant는 핵심 메이븐 플러그인처럼 사용할 수 있고, 수정된 Maven 플러그인들이 Ant에 구현될 수 있으며, Maven 프로젝트는 Maven 프로젝트의 생명주기 내에서 Ant 스크립트를 실행하도록 설정이 가능하다.


Appendix. 최근에는 Maven이후 Gradle이라는 것이 등장했다.

Maven과 Gradle에 대한 이야기는 아래의 링크를 참고해 보면 좋겠다.

http://kwon37xi.egloos.com/4747016

http://kwonnam.pe.kr/wiki/gradle/from_maven


참고 레퍼런스:

http://www.javafaq.nu/java-article1168.html

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


Posted by 알 수 없는 사용자
,

1. Maven 소개


이전에는 자바 프로젝트를 시작할 때 제일 먼저하는 작업이 이클립스를 띄우고, 자바 프로젝트를 만들어 라이브러리를 lib폴더에 추가하는 것이었다. 이러한 과정에 들어가기 전에 아래와 같은 고민이 생겼다.


1.프로젝트가 빌드에 필요한 것이 무엇인가? 

2.다운로드 받을 필요가 있는 라이브러리가 어떤 것인가? 

3.다운로드 받은 것을 어디에 넣어야 하는가? 

4.빌드에서 어떤 goal을 실행할 수 있는가? 


이런 고민 때문에  잘될때는 새로운 프로젝트의 빌드를 해결하는데 최소 몇분이 걸리고, 잘 되지 않을 때는 프로젝트의 빌드가 어려워서 새로운 개발자가 소스를 수정하고 프로젝트를 컴파일하는 지점에 도달하는데 수시간이 걸리는 현상이 발생하였다. 

이렇게 매번 비슷한 라이브러리를 사용하는 자바프로젝트를 계속 만들다 보면 매번 똑같은 작업을 반복하여야 했고, 이러한 삽질을 해결해 주기위해 등장한 것이 Maven이다.



사실  Maven 탄생이전에 이러한 문제점을 해결해주기 위해 Ant라는 빌드툴이 있었는데 여기서 좀 더 개선된 것이 Maven이다.

물론  Ant보다 Maven이 더 우월하다고 결론을 내릴 수는 없는데 이와 관련된 내용은 다음 포스팅에서 다룰 것이다.


2. Maven의 동작원리


이제 Maven의 동작원리에 대해 간단히 알아보자.





1.개발자 A가  "embian"이라는 라이브러리를 만들었다.

1.1 이 라이브러리는 완벽하지 않고, 다른기능을 추가해야 할수 있다. 

1.2 그래서 여러 개발자가 필요시 이 라이브러리를 사용해야 한다


2. 라이브러리를 만들고 난후 Maven툴을 이용하여 빌드 한 후 서버에 올린다.(a)


3. 개발자 B와 개발자C가 "embian"라이브러리가 필요한 경우 프로젝트마다 설정되어 있는 "pom.xml"이라는 파일을 설정하면 Maven툴이 알아서 서버에 접속하여 "embian"라이브러리를 다운받아 자신의 프로젝트에 자동으로 추가한다.(b)


4.필요에 따라 "pom.xml" 파일을 설정하면 Maven툴은 주기적으로 서버와 통신하여 최신버전의 "embian"라이브러리를 다운받게 할 수 있다. 개발자 A 혹은 다른 개발자가 "embian"라이브러리를 수정하여 서버에 업로드 할 수 있기 때문이다. (a)


5."embian"라이브러리를 사용하는 "embian2"라는 라이브러리가 있을 경우 Maven툴은 알아서(의존성을 체크하여) "embian2"와 "embian"라이브러리를 다운받는다.


6. Maven툴은 여러 플러그인을 hudson이나 Ant,Nexus등의 유명툴과 연동할수 있다.



3.정리 
Maven을 소개하고 동작원리까지 알아보았으니 이제 정리하면서 다시 한번 말해 Maven 무엇일까?

답은 여러분의 관점에 달렸다.

대부분의 Maven사용자들은 Maven 소스 코드로부터 배포 가능한 산출물을 만드는데 사용되는 도구인 "build tool"이라고 부를 것이고, 빌드 담당자와 프로젝트 매니저들은 Maven을 프로젝트 관리 툴로서 더 종합적인 무언가 라고도 할것이다.

Maven 같은 프로젝트 관리 도구는 빌드 도구에서 발견되는 기능의 상위 개념을 제공한다. 빌드 기능을 제공하는 이외에Maven 레포트를 실행하고, 사이트를 만들며, 작업 팀의 멤버 간의 커뮤니케이션을 가능하게 해준다.


다음은 Apache Maven 공식적인 정의이다

Maven 프로젝트 객체 모델 (Project Object Model), 표준의 집합, 프로젝트 라이프사이클, 의존성 관리 시스템, 라이프사이클 정의된 단계에서 플러그인 목표를 실행하는 논리를 포함하는 프로젝트 관리 도구이다. 여러분이 Maven 사용할 정의된 프로젝트 객체 모델을 사용한 프로젝트를 기술하며Maven 다음에 공유된(혹은 사용자가 만든) 플러그인들로부터 cross-cutting 로직 적용할 수 있다.  Maven이 프로젝트 관리 도구라는 사실에 두려움을 느끼겠지만 만약 당신이 빌드 도구를 찾는다면 Maven이 그 역할을 수행할 것이다.


Maven이 성공할 수 있었던 핵심 근거는 소프트웨어를 빌드하는데 공통 인터페이스를 정의했다는 것이다.아파치 Wicket과 같은 프로젝트가 Maven 사용하는 것을 살펴보면 소스를 체크아웃 받고 부담없이 mvn install을 사용해서 빌드를 한다.

쉽게 설명하자면 자동차 키를 어디에 꽂는지 알고 있으며, 가속 페달이 오른쪽에 위치하고 브레이크가 좌측에 위치한다는 것을 알고 있다는 것이다.


이렇게 Maven에 대해 알아보았으니 다음 포스팅에는 Maven을 설치하고 간단한 프로젝트를 소개하는 포스팅을 하도록 하겠다.

그럼 See you soon~!



참고자료: 

Maven:the Definitive Guide -O'Reilly Media, Inc.

http://blog.naver.com/sidoheba?Redirect=Log&logNo=110179097295

http://oreilly.com/catalog/mavenadn/chapter/ch01.pdf

http://wiki.javajigi.net/display/IDE/Maven


Posted by 알 수 없는 사용자
,