Roel Notebook

[common] Maven이란?

by Roel Downey

Web

728x90
반응형

Maven이란?

Maven은 지금까지 애플리케이션을 개발하기 위해 반복적으로 진행해왔던 작업들을 지원하기 위하여 등장한 도구이다. 

Maven을 사용하면 빌드(Build), 패키징, 문서화, 테스트와 테스트 리포팅, git, 의존성관리, svn등과 같은 형상관리서버와 연동(SCMs), 배포 등의 작업을 손쉽게 할 수 있다.

 

Maven을 이해하려면 CoC(Convention over Configuration)라는 단어를 먼저 이해해야 한다.

CoC란 일종의 관습을 말하는데, 예를 들자면 프로그램의 소스파일은 어떤 위치에 있어야 하고, 소스가 컴파일된 파일들은 어떤 위치에 있어야 하고 등을 미리 정해놨다는 것이다.

이 말은 관습에 이미 익숙한 사용자는 쉽게 Maven을 사용할 수 있는데, 관습에 익숙하지 않은 사용자는 이러한 제약사항에 대해서 심한 거부감을 느낄 수 있다.

Maven을 사용한다는 것은 어쩌면 이러한 관습 즉 CoC에 대해서 알아나가는 것이라고도 말할 수 있다. 

 

 

Maven을 사용할 경우 얻게 되는 이점은?

Maven을 사용할 경우, 굉장히 편리한 점들이 많다.

장점 : 편리한 의존성 라이브러리 관리가 있다.

Maven을 사용하면 설정 파일에 몇 줄 적어줌으로써 직접 다운로드 받거나 하는 것을 하지 않아도 라이브러리를 사용할 수 있다.

Maven을 사용하게 되면 Maven에 설정한 대로 모든 개발자가 일관된 방식으로 빌드를 수행할 수 있게 된다.

Maven은 또한 다양한 플러그인을 제공해줘서, 굉장히 많은 일들을 자동화시킬 수 있다.

 

Maven 기본

Archetype을 이용하여 Maven 기반 프로젝트를 생성할 경우 생성된 프로젝트 하위에 pom.xml 파일이 생성된다.

pom.xml 파일을 살펴보면 다음과 같다.

<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/maven-v4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>kr.roel</groupId>
    <artifactId>examples</artifactId>
    <packaging>jar</packaging>
    <version>1.0-SNAPSHOT</version>
    <name>mysample</name>
    <url>http://maven.apache.org</url>
    <dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>3.8.1</version>
            <scope>test</scope>
        </dependency>
    </dependencies>
</project>

각각의 태그의 의미는 다음과 같다.

  • project : pom.xml 파일의 최상위 루트 엘리먼트(Root Element)이다.
  • modelVersion : POM model의 버전이다. 
  • groupId : 프로젝트를 생성하는 조직의 고유 아이디를 결정한다. 일반적으로 도메인 이름을 거꾸로 적는다.
  • artifactId : 해당 프로젝트에 의하여 생성되는 artifact의 고유 아이디를 결정한다. Maven을 이용하여  pom.xml을 빌드할 경우 다음과 같은 규칙으로 artifact가 생성된다. artifactid-version.packaging. 위 예의 경우 빌드할 경우 examples-1.0-SNAPSHOT.jar 파일이 생성됩니다.
  • packaging : 해당 프로젝트를 어떤 형태로 packaging 할 것인지 결정한다. jar, war, ear 등이 해당된다.
  • version : 프로젝트의 현재 버전. 추후 살펴보겠지만 프로젝트가 개발 중일 때는 SNAPSHOT을 접미사로 사용된다. 
  • name : 프로젝트의 이름이다.
  • url : 프로젝트 사이트가 있다면 사이트 URL을 등록하는 것이 가능하다.

Maven 을 이용할 경우 얻게 되는 큰 이점 중의 하나는 Dependency Management 기능이다.

위 pom.xml 파일에서 <dependencies/> 엘리먼트가 Dependency Management 기능의 핵심이라고 할 수 있다.

해당 엘리먼트 안에 필요한 라이브러리를 지정하게 된다.

 

POM.xml

pom.xml 은 메이븐을 이용하는 프로젝트의 root에 존재하는 xml 파일이다. pom은 프로젝트 객체 모델(Project Object Model)을 뜻한다. 프로젝트 당 1개가 있다. 이것만 보면 프로젝트의 모든 설정, 의존성 등을 알 수 있다!!

엘리먼트

  • <groupId> : 프로젝트의 패키지 명칭

  • <artifactId> : artifact 이름, groupId 내에서 유일해야 한다.

<groupId>org.springframework</groupId> 
<artifactId>spring-webmvc</artifactId>
  • <version> : artifact 의 현재버전 ex. 1.0-SNAPSHOT

  • <name> : 어플리케이션 명칭

  • <packaging> : 패키징 유형(jar, war 등)

  • <distributionManagement> : artifact가 배포될 저장소 정보와 설정

  • <parent> : 프로젝트의 계층 정보

  • <dependencyManagement> : 의존성 처리에 대한 기본 설정 영역

  • <dependencies> : 의존성 정의 영역

  • <repositories> : 이거 안쓰면 공식 maven 저장소를 활용하지만, 사용하면 거기 저장소를 사용

  • <build> : 빌드에 사용할 플러그인 목록을 나열

  • <reporting> : 리포팅에 사용할 플러그인 목록을 나열

  • <properties> : 보기좋게 관리가능, 보통 버전에 많이 쓴다.

<!-- properties 에 이렇게 추가하면 --> 
<spring-version>4.3.3.RELEASE</spring-version> 

<!-- dependencies 에 이렇게 쓸수 있다. --> 
<version>${spring-version}</version>

 

 

<modelVersion>4.0.0</modelVersion> 
<!-- The Basics --> 
<groupId>...</groupId> 
<artifactId>...</artifactId> 
<version>...</version> 
<packaging>...</packaging> 
<dependencies>...</dependencies> 
<parent>...</parent> 
<dependencyManagement>...</dependencyManagement>
<modules>...</modules> 
<properties>...</properties> 
<!-- Build Settings --> 
<build>...</build> 
<reporting>...</reporting> 
<!-- More Project Information --> 
<name>...</name> 
<description>...</description> 
<url>...</url> 
<inceptionYear>...</inceptionYear> 
<licenses>...</licenses> 
<organization>...</organization> 
<developers>...</developers> 
<contributors>...</contributors> 
<!-- Environment Settings --> 
<issueManagement>...</issueManagement>
<ciManagement>...</ciManagement> 
<mailingLists>...</mailingLists> 
<scm>...</scm> 
<prerequisites>...</prerequisites> 
<repositories>...</repositories> 
<pluginRepositories>...</pluginRepositories> 
<distributionManagement>...</distributionManagement> 
<profiles>...</profiles>


메이븐 라이프 사이클

메이븐은 프로젝트 생성에 필요한 단계(phases)들을 Build Lifecycle이라 정의하고 default, clean, site 세가지로 표준 정의한다. Lifecycle은 Build Phase 들로 구성되며 일련의 순서를 갖는다. phase 는 실행단위로서 goal과 바인딩된다.

아래 사진은 Build default 라이프사이클의 주요 phase이고 그 밑에는 전체이다.

 

 

  • clean : 빌드 시 생성되었던 산출물을 삭제
    1. pre-clean : clean 작업 전에 사전작업
    2. clean : 이전 빌드에서 생성된 모든 파일 삭제
    3. post-clean : 사후작업
  • default : 프로젝트 배포절차, 패키지 타입별로 다르게 정의됨
    1. validate : 프로젝트 상태 점검, 빌드에 필요한 정보 존재유무 체크
    2. initialize : 빌드 상태를 초기화, 속성 설정, 작업 디렉터리 생성
    3. generate-sources : 컴파일에 필요한 소스 생성
    4. process-sources : 소스코드를 처리
    5. generate-resources : 패키지에 포함될 자원 생성
    6. compile : 프로젝트의 소스코드를 컴파일
    7. process-classes : 컴파일 후 후처리
    8. generate-test-source : 테스트를 위한 소스 코드를 생성
    9. process-test-source : 테스트 소스코드를 처리
    10. generate-test-resources : 테스팅을 위한 자원 생성
    11. process-test-resources : 테스트 대상 디렉터리에 자원을 복사하고 가공
    12. test-compile : 테스트 코드를 컴파일
    13. process-test-classes : 컴파일 후 후처리
    14. test : 단위 테스트 프레임워크를 이용해 테스트 수행
    15. prepare-package : 패키지 생성 전 사전작업
    16. package : 개발자가 선택한 war, jar 등의 패키징 수행
    17. pre-integration-test : 통합테스팅 전 사전작업
    18. integration-test : 통합테스트
    19. post-integration : 통합테스팅 후 사후작업
    20. verify : 패키지가 품질 기준에 적합한지 검사
    21. install : 패키지를 로컬 저장소에 설치
    22. deploy : 패키지를 원격 저장소에 배포
  • site : 프로젝트 문서화 절차
    1. pre-site : 사전작업
    2. site : 사이트문서 생성
    3. post-site : 사후작업 및 배포 전 사전작업
    4. site-deploy : 생성된 문서를 웹 서버에 배포

 

728x90
반응형

블로그의 정보

What doing?

Roel Downey

활동하기