Maven 설치 1

Maven Step By Step Spring w/ Maven 2012/03/07 17:35 http://jejoong76.blog.me/70133184061

   

구축중인 사이트에서 Maven 을 적용하며 구축과 활용에 필수적인 내용을 정리하기로 했다.

틈틈히 시간내서 정리해 보아요.

개인적인 궁금증에서 알아가는 과정에서 정리한 것들로, 내용적 오류가 있으면 현란한 비판을

해줘도 괜춘함.

   

0. 왜 Maven 을 고려하였는가.

1. 설치 및 디렉토리 설명.
2. 용어설명
3. 실행 명령어 
4. Maven에서 lifeCycle 이란.  
5. pom.xml
6. setting.xml
7. repository
  7-1 사내저장소 운영
    nexus repository 의 설명 및 project 에서의 세팅 nexus 연동 세팅(setting.xml등)

8. hudson 
 8-1 환경설정 및 용어설명
 8-2 빌드 및 배포 설정
 8-3 CI 툴 로서의 이용. 

 

 

0. 왜 Maven 을 고려하였는가. Why Maven? Spring w/ Maven 2012/01/30 21:57 http://jejoong76.blog.me/70130105395

0. 왜 Maven 을 고려하였는가. Why Maven?

   

썰.

벌써 작년.. 일년이 되어가는 구나.. 프로젝트를 새로 시작하게 되었다.

이번 프로젝트의 특징은 하나의 사이트 개발에 여러 업체가 비지니스별로 개발을 진행하게 되며, 연이어 곧 이와 유사한 구조의 사이트가 하나 더 개발될 예정이다.

   

나의 소임을 정리해보니.

   

개발 총괄로서 각 개발분의 취합 및 빌드 후 적용.

플러스.

개발자로서 일정부분 비지니스로직 및 웹의 개발.

플러스.

DB의 설계.

플러스.

웹&DB&메일 등등의 서버 세팅.

플러스.

음.... 결론적으로다가. 바쁘게 생겼다. 

   

그럼..관련 개발자님들. JDK ,Spring 버전은 몇이고, DB는 익숙하진 않지만 비용문제로 Mysql로 갑니다. 화이팅하시죠.. 하고 프로젝트 kick offed.

   

이렇게 해서 몇일이 흐르고, 중요한 문제에 직면하게 된다.

각 개발자별 외부라이브러리 버전 문제로, 개발 총괄로서 빌드에 삽질을 수일. 더이상은 안되겠다는 결론에 도달하게 된다.

그래. 익숙치 않지만, 한창 말 나오는 메이븐이라는 걸 쓰면, 개발총괄의 일을 좀 덜어지겠나?

(결국 일을 덜진 않았던 것 같다.)

   

암튼, Why Maven?? 왜 maven을 선택했었던가에 대해 생각해보면,

이랬던거 같다.

  -의존관계 라이브러리 관리.
     개발자의 외부라이브러리(프레임웤관련 같은.jar but 상이 lib버전-발생원인: 특정 외부라이브러리들중에 다른버전의 라이브러리의존의 경우로 인해 빌드 실패 발생.
     각자 필요한 lib를 로컬서버에 복사해서 작업하다가, 나중에 커밋 후 다른버전의 라이브러리 발생. pom.xml 로 의존라이브러리 공유하여 개발하도록 유도하며,
     접근 가능한 저장소를 지정(사내 라이브러리 저장소)해서, 외부라이브러리 표준화를 컨트롤 할 수 있겠다.)
 

- 프로젝트 템플릿을 만들어 신규 프로젝트를 진행할때 동일한 구조에서 작업을 유도할 수있겠다...(심플한 구조에서 개발이 진행되니 유지보수시 이해하기 편하겠군.),

   

- 사이트내 필수 프레임웤(spring, ibatis, sns api,site-mesh 등)에 의존적인 lib에대한 별도의 다운로드가 필요없어 개발환경 세팅에 편리성 제공.

- hudson(CI툴)로 단위테스트도 기획했으나, 시간 압박으로 인해, 단위테스트는 그냥 이클립스에서하고.. 아쉽게도 HUDSON은 그냥 빌드&디플로이 용도로만 사용.

   

   

메이븐 도입하면서 단점은..

 ant에 익숙한 개발자들의 초기 진입장벽이 높음. 초기 개발 설정 비용이 증가. 관리차원에서는 편리할 수있으나, 개발시에는 ant 또는 이클립스 컴파일러가 익숙한 개발자들에게는 초기 부담을 줬던거 같다. 나도 많이 익숙치 않으터라 교육도 충분치 못했고..

   

암튼. 일단 새신을 신었으니, 걷기라도 해보자는 심정으로 일을 벌였다. " 여러분 개발환경에 약간의 변동이 있겠습니다. maven 프로젝트로 .. -,-;;"

   

그래서, 나의 고생했던 것과  알아낸 것들을 꼭 log를 남기리라 결심했고, 이제서야 행동으로 옮기는 구나..

 

 

1. 설치 및 디렉토리 설명 (Maven 설치) Spring w/ Maven 2012/03/09 12:42 http://jejoong76.blog.me/70133310641 첨부파일 (1)

메이븐을 이용한 개발환경을 갖추려면, 로컬, 서버에 메이븐이 설치 되어있어야 한다. 

로컬: 개발 및 테스트

서버: 테스트 및 배포

   

설치는 간단하다.

   

로컬에서 설치 



1. 다운로드

 http://maven.apache.org/download.html 에서 다운받을 버전 선택하여 다운로드.

혹은 (http://www.apache.org/dyn/closer.cgi/maven/binaries/apache-maven-3.0.4-bin.zip)

   

2. C:/maven 에 압축을 푼다.

   

3. 환경변수 등록

변수 : MAVEN_HOME

값: C:/maven/apache-maven-3.0.4

   

4.시스템변수 등록

Path 에 %MAVEN_HOME%/bin; 추가

   

5. 도스창에서 mvn -v 로 버전 및 설치 확인.

   

   

이클립스에 메이븐 개발환경 세팅

   

1. 메뉴에서 HELP > Install New Software

   

work with : http://m2eclipse.sonatype.org/sites/m2e

Maven Integration for Eclipse

   

work with:  http://m2eclipse.sonatype.org/sites/m2e-extras

Maven Integration for Eclipse Extras *
Maven Integration for Eclipse WTP

설치 완료.

   

   

리눅스 서버에 설치

   

1. 다운로드

http://maven.apache.org/download.html 에서 다운받을 버전 선택하여 다운로드.

혹은 http://apache.tt.co.kr//maven/binaries/apache-maven-3.0.4-bin.tar.gz

   

2. 압축풀기

mv ./apache-maven-3.0.4-bin.tar.gz /usr/local/maven

tar -xvzf /usr/local/maven/apache-maven-3.0.4-bin.tar.gz

   

3. 모든 사용자에게 maven 권한을 주는 경우의 환경변수 세팅

/etc/profile.d/ 

디렉토리에 mavenenv.sh  의 파일을 생성.

   

vi mavenenv.sh 로 해당 파일을 하단 내용으로 편집함.

   

M2_HOME=/usr/local/apache-maven
M2=$M2_HOME/bin
PATH=$M2:$PATH

   

export PATH

   

저장하고 나오고.  (:wq)

   

환경변수 추가하면 항상 적용.

source /etc/profile.d/mavenenv.sh

   

#export 해보면 PATH 에 메이븐 bin 디렉토리가 포함되어 있을꺼임.

   

#mvn -v 로 구동 확인. 뭐라뭐라 시스템 정보가 나오면 성공.

 

 

2. 용어설명 (maven 관련 용어정리) Spring w/ Maven 2012/03/07 17:47 http://jejoong76.blog.me/70133184984

2. 용어설명 (maven 관련 용어정리)

   

archetype(아키타입) 

메이븐은 프로젝트의 종류에 맞는 기반 프로젝트 템플릿을 생성해준다.

템플릿 생성시 소스,테스트,웹리소스 디렉토리의 뼈대를 만들어 주는데,

archetype 에 명시해 주는 타입으로 프로젝트의 템플릿을 생성하게 된다.

   

groupId

그룹아이디는 지금 하고있는 프로젝트를 식별하게 해주는 식별자이다.

보통 프로젝트할때 라이브러리를 구성하는 소스파일들이 위치하는 기본 디렉토리를 일컫는다고

보면되겠다..

통상 kr/co/myhome/blahblah*.java(s) 이런식으로 프로젝트의 디렉토리를 만든다고 할때,

groupId=kr.co.myhome 이 되는 거임.

   

artifactId

해당 프로젝트에서 여러개의 생성물(artifact)이 생겨난다고 할때, 생성물별 고유아이디 되겠다.

   

예를 들어,

org/apache/maven

                           /artifact

                           /repository

                           /io

                           /merge

                           ...

와 같은 프로젝트가 있고,

maven-artifact.jar 은 /artifact , /repository

를 포함하는 패키지이고,

maven-model.jar 은 /io , /merge 

을 포함하는 패키지이면,

각각의 패키지는 고유 식별자의 artifactId 를 가지게 된다.

   

보통 하나의 프로젝트에서 하나의 패키지를 만드는 경우엔

프로젝트 명을 artifactId 로 쓴다. 



** 라이브러리는 maven 중앙저장소에서 관리되기에, groupId+artifactId 는

유일한 식별자가 되어야, 중앙저장소에서 충돌을 피할 수 있다.