Community|
Space Map
|
Eclipse를 활용한 효율적인 팀 개발 및 배포 전략0. 목차
0. 소개이 문서는 오픈 소스 자바 어플리케이션을 개발하기 위해 이클립스가 어떻게 사용될 수 있는지에 대해 설명한다. 팀 개발을 위해서 CVS 등의 버전관리 툴과 함께 이클립스를 사용하는 방법에 대하여 알아보고, Ant, Maven 등을 통한 빌드 자동화 시스템에 대해서 알아보도록 한다. Eclipse 는 버전 3.1 을 이용하였다. CVS 와 Ant 등을 이용한 개발 프로세스는 다음과 같다.
1. CVS 등을 통한 효율적인 팀 개발소프트웨어 개발 환경에서 기술적으로 가장 중요한 것은 소스 버전 관리이다. 개발팀에서 작성하는 모든 소스는 버전 관리가 되어야 한다. 프로그램 소스는 물론이고 스크립트, SQL, 각종 문서, 설정 파일들까지 포함해야 한다. 소스 버전 관리의 목적은 작업 기록의 보존을 통해 문제가 발생했을 때 원인을 추적하거나 이전 상태로 되돌리기 위한 것이다. 또한 이러한 정보로 버그 추적이나 감사(audit), 퍼포먼스, 품질 관리 목적에 사용할 수도 있다. 보통 소스 버전 관리를 위해서 CVS(Concurrent Versions System)를 많이 사용한다. CVS는 80년대부터 개발되어 오고 있으며, 오픈 소스 개발을 위한 사실 상의 표준이 되어 버린 버전 제어 도구이다. CVS를 좀 더 개선한 Subversion도 있고 여러 가지 상용 툴도 있지만 여전히 CVS가 오픈소스 공동체에서 가장 많이 쓰이며 IDE와도 잘 통합되어 있다. 소스 관리는 사실 SCM(Software Configuration Management)의 일부분이기도 하다. SCM은 소스에 대한 버전 관리 뿐 아니라 소프트웨어의 기능성 수준에 대한 변동 기록, 버그 수정 내역, 요구사항의 변화 등을 종합적으로 관리하는 것을 말한다. 소프트웨어의 새 버전이 발표되면 보통 릴리스 노트(Release Notes)가 같이 배포되는데 이런 것이 SCM의 대표적인 산출물이다. 상용 SCM 툴도 많지만 보통은 소스 관리에 CVS를 쓰고 이외에는 이슈 트래커를 쓰는 것으로 SCM의 대부분의 영역이 커버됩니다. 소스 외의 형상 관리는 사실 업무 요청 관리와 기능적으로 아주 비슷하기 때문이다. 오픈소스와 친한 사람이라면 버그질라(bugzilla)를 접해본 적이 있을 것이다. 버그를 보고하고 버그가 수정되는 과정을 기록으로 남기고 조회할 수 있게 해주는 시스템이다. 여기서는 eclipse 에서 제공하는 CVS 기능과 기타 plugin 을 통해 소스코드를 개발 팀과 공유하는 기능을 알아보고, 효율적인 버전관리 방법에 대해 살펴보도록 하자. 1.1 CVS 및 기타 버전관리툴 소개1.1.1 CVS 개념먼저 몇 가지 기본적인 CVS 개념을 살펴보자.
CVS 저장소CVS 서버는 다수의 모듈(modules)을 포함하고 있는 저장소(repository)를 관리한다. java.net의 저장소의 경우 개별 프로젝트는 자신만의 모듈을 가지고 있다. 모듈은 디렉토리와 함께 버전이 부여된 파일을 포함하고 있다. 버전이 부여된 파일은 하나의 파일에 대한 이력을 나타내며, 다수의 개정 이력(revisions)을 포함한다. 파일에 변경이 가해질 때마다, 새로운 개정본(revision)이 생성된다. .java, .xml, .properties 등의 텍스트 기반 파일의 경우, 각각의 개정본은 이전 개정본에서 개정된 내역만을 포함하며, .exe, .jar, .pdf 등의 이진 파일의 경우, 각각의 개정본은 완전한 파일 내용을 포함하게 된다. CVS는 또한 개정본 생성자와 개정본에 대한 주석, 그리고 개정본 번호도 함께 기록한다. 개정본 번호들은 자동으로 갱신되는데, 대부분의 경우, 파일의 첫번째 개정본 번호는 1.1이고 이후에는 1.2 등의 순서로 갱신된다. repository
moduleA/
versionedFile1
(revision number="1.1" user="dave" comment="Created")
(revision number="1.2" user="mike" comment="New cache implementation")
(revision number="1.3" user="lucy" comment="Fixed defect D113")
versionedFile2
(revision number="1.1" user="dave" comment="Created")
(revision number="1.2" user="dave" comment="Updated after feedback from Lucy")
directory1/
versionedFile3
(revision number="1.1" user="lucy" comment="Initial version")
...
moduleB/
...
저장소 접속과 권한CVS 클라이언트는 다양한 프로토콜을 사용하여 서버에 접속할 수 있다. 가장 일반적으로 사용되는 프로토콜은 다음과 같다:
작업을 수행하기 위한 파일 사본 가져오기(checkout)저장소에 접속한 이후에는 하나 이상의 모듈을 가져올 수 있다. 이를 checkout 이라고 하는데, *체크아웃*을 하면 CVS에서 여러분의 컴퓨터로 모듈의 최신 내용이 복사되어, 여러분은 모듈 복사본을 가지고 원하는 작업을 수행할 수 있게 된다. 동기화(synchronize), 갱신(update), 작업 공간의 수정 사항 반영(commit)CVS 클라이언트를 사용하여 로컬 파일과 저장소 파일 사이의 *동기화*를 할 수 있다. 동기화 과정에서 로컬 파일과 CVS의 최신 모듈 사이의 차이점을 볼 수 있다. 이러한 차이들은 다음과 같이 분류 할 수 있다:
충돌(conflict)CVS는 자동적으로 저장소의 변경 사항과 작업 공간의 변경 사항 가운데서 충돌하는 내용을 감지한다. 개발자 A와 B가 동시에 같은 파일을 수정하고, A가 먼저 이를 저장소에 반영(commit)하고 난 후에 곧바로 B가 자신이 변경한 내용을 저장소에 반영하려고 할 때 이러한 충돌이 발생한다. 아래 다이어그램을 보자. 숫자로 된 화살표는 일의 발생 순서를 나타낸다. Alice가 Bob보다 먼저 변경사항을 저장소에 반영하고 Bob이 동기화를 하게 되면 Bob은 상충이 발생했다는 것을 알게 된다.  충돌나는 변경 사항 해결하기파일에서 상충되는 변경 사항이 발견 될 경우, 파일을 저장소에 반영하기 전에 상충되는 변경 사항에 대해 병합(merge, integrate)을 수행해야 한다. CVS는 한 파일의 서로 다른 행의 변경 사항들에 대한 병합은 자동으로 수행한다. 다만 같은 행에서 변경이 발생할 경우, 개발자가 직접 병합 을 실행해야 한다. 나중에 보겠지만 이클립스는 개발자의 병합을 돕는 매우 훌륭한 GUI를 제공한다. 수정중인 작업자 추적CVS에서는 동시 수정 가능 잠금 방식(optimistic locking)을 사용하여 누구라도 CVS 저장소에 접근에 동시에 파일을 수정 가능하지만, 누가 어떤 것을 수정하고 있는지 알아낼 수 있도 있다. 파일 수정 작업을 시작할 경우, 클라이언트가 이 사실을 서버로 알리도록 설정될 수 있다. 만약 누군가 파일을 수정하려고 하면 이미 그 파일이 수정 중이라는 경고를 받을 수 있다. 이것은 수정 사항의 충돌을 피하는 유용한 방법이다. (저장소의 파일을)동시 수정 가능 잠금 방식(Optimistic locking) 버전 관리 도구에 따라 저장소에 위치한 파일을 한 사람이 가져가는 경우 해당 파일에 대해 잠금(locking)을 적용한다. 잠금 상태에서는 체크아웃 한 사람이 파일을 다시 저장소로 보내기 전까지는 아무도 파일에 대한 수정 작업을 할 수 없게 된다. 이렇게 엄격하게 잠금을 하는 방식의 버전 관리의 단점은, 종종 다른 개발자들의 수정 작업이 끝날 때까지 대기해야 한다는 점이다. 또한 체크아웃하고 나서 체크인하지 않을 경우, 자신도 모르게 수정도 하지 않는 파일을 잠궈 버리게 된다. CVS는 잠금을 필요로 하지 않는 동시 수정 가능 방식을 사용한다. 개발자들은 CVS의 충돌 사항을 발견하는 기능을 통해, CVS에서 가져온 파일을 동시에 수정할 수 있다. 충돌나는 사항이 발견될 경우, CVS에서는 이를 해결해주는 도구를 제공한다. 이러한 방식은 위험해 보일 수 있지만, 실제 개발 환경에서는 매우 유용한 방식이다. 아예 충돌이 나는 일 자체를 피하고 싶다면 CVS가 제공하는 파일에 대한 작업자 추적 정보를 이용할 수 있다. 태그(tagging)개발할 때 여러분은 종종 다음과 같은 이정표(milestones)들에 도달하게 된다:
사용자는 모듈의 태그가 부여된 개정본을 저장소에서 가져올 수 있다. 설령 태그가 삭제되거나 변경되었다 하더라도 태그가 붙었던 버전의 모듈 내용물은 항상 같을 것이다. 분기(branches)와 HEAD분기(branch)는 일련의 독립적인 개발 흐름을 유지하기 위해 쓰인다. 기본적으로 저장소의 내용과 작업 공간의 내용의 동기화를 위해 update나 commit 명령을 사용하면, HEAD라고 불리는 기본 분기(trunk 라고도 불리운다) 상에서 작업이 이루어진다. 사용자는 필요에 따라 새로운 분기를 생성할 수 있다. 분기는 항상 루트 태그(root tag)라 불리는 태그부터 반드시 시작되어야 하며, 루트 태그의 이름에는 특별한 규칙이 없다. 분기를 사용하는 목적인 대개 공식 배포(release)의 병렬적인 개발을 관리하기 위함이다. 예를 들어 어플리케이션의 1.4 버전을 공식 배포(Release) 했고 계속해서 HEAD 분기에서 2.0 버전을 개발하기 시작했다고 해보자. 만약 치명적인 버그가 1.4 에서 발견되었다는 사용자의 보고가 있다면 RELEASE1-4-0을 루트 태그로 사용하여 분기를 만들 수 있다.  분기 상에서 작업을 시작했을 때, 모듈 내용은 1.4 정식 배포 버전과 완전 동일할 것이다. 이후부터 저장소와의 동기화는 해당 분기에만 적용될 것이다. 태그는 HEAD에서 정의되는 것과 마찬가지로 다른 분기에서도 정의 될 수 있다. 가능하다면 한 수준 정도(one level)의 분기를 고수하는 것이 가장 좋지만, HEAD 이외의 분기에서도 또 다른 분기를 만들 수 있다.
분기의 병합(merge)필요한 경우에 변경 사항을 특정 분기에서 다른 분기로 병합 할 수 있다. 예를 들어 위 그림에서, 버그를 수정한 1.4.1의 변경 사항을 2.0.0 정식 배포판에 포함시키기 위해서 HEAD 분기로 병합을 할 수 있다. 두 개의 분기 사이의 병합은 저장소와 작업공간의 변경 사항 동기화와 유사하며, 마찬가지로 상충이 발생하는 경우는 이클립스 GUI를 활용하면 좀 더 수월하게 해결할 수 있다. 이력(history) 및 차이점 보기(diff)CVS는 개별 파일이나 파일 조합의 변경 이력을 볼 수 있는 다양한 방법을 제공한다. 또한, CVS를 이용하면 각각의 수정본, 태그 그리고 분기들 사이의 차이를 볼 수 있다. 참고 자료
1.1.2 기타, SubVersion, VSS(Visual Source Safe), Perforce
1.2 eclipse 설정과 기본 사용법cvsnt설치 및 eclipse 에서 cvs연결하는 방법은 다음의 사이트들을 통해 익힐수 있다. 제대로 연결 되었다면 CVS Repositories perspective 에서 다음 화면을 볼수 있다. 1.3 SCM Best Practices지금까지는 사용법에 관해 알아보았다. 실제 팀내 개발이 제대로 이루어지려면 모든 개발자들이 사용법 숙지를 기본으로 해야 한다. 프로젝트가 커지고 모듈이 많아지고 릴리스가 계속 되고 있는 복잡한 제품을 관리하고 있다면 이런 것 외에 알아야 할 것이 더 있다. 1.3.1 GUI 툴 사용자동화와 관련된 것이 아니라면 콘솔창은 매우 불편하다. 우리의 두뇌를 명령어 익히는 작업에서 보다 고차원적인 일을 하도록 유도해야 한다. eclipse를 사용한다면 대부분의 SCM 이 plugin 형태로 지원되므로 history, diff, merge등을 편하게 사용할 수 있다. Windows 사용자라면 TortoiseCVS(추천), WinCVS 등을 이용하면 revision graph 등 CVS 를 좀 더 편하게 사용할 수 있고, Araxis Merge 같은 상용 merge 툴을 사용해도 좋다. 1.3.2 개발자 작업공간(Workspace or Sandbox)개발자가 빌드, 테스트, 디버그를 하는 공간이다.
1.3.3 소스 코드 라인(Codelines)소스 파일들의 의미있는 집합을 얘기한다.
1.3.4 브랜칭(Branching)새로운 코드라인을 만드는 것을 의미한다.
1.3.5 변경사항 전파(Propagation)와 병합(Merging)한쪽 코드라인에서 변경된 사항을 다른 쪽에도 반영시키는 것을 말한다.
1.3.6 소프트웨어 빌드(Builds)소스 파일을 제품으로 바꾸는 과정이다.
1.3.7 조직에서 제도화하기(Process]위의 모든 과정들의 규칙.
1.3.8 결론"툴은 잘 사용했을 때 좋은 것이다". 단순히 CVS , Subversion, Clearcase, perforce, accurev, 등의 SCM 툴을 설치하고 명령어 몇개를 사용한다고만 해서 제대로 쓰고 있다는 것은 아니다. 프로그래밍 언어만 안다고 해서 프로그래밍을 잘 안다고 할 수 없듯이, SCM 툴을 활용하는 데도 그만한 시간과 노력이 필요하다.
2. 빌드 및 배포 자동화프로젝트 컴파일은 귀찮은 일이다. 믿을 만하고 반복가능하게 만들어야 한다. 일관성과 정확성을 보장하는 훌륭한 방법은, 팀이 하는 모든 일을 자동화하는 것이다. XP(Extreme Programming)의 지속적인 통합(Continuous Integration)에서는 빌드 자동화를 가장 중요하게 다룬다. 빌드는 비어 있는 디렉토리 하나를 가지고 프로젝트를 밑바닥에서부터 만드는 과정으로, 무엇이건 여러분이 생산해 내고 싶은 최종 제품을 만들어 낸다.
잘 관리되고 있는 프로젝트는 매일 빌드(daily builds)를 한다. 매일 야밤에 빌드를 수행하여 그 성공/실패 결과를 이메일등을 통해 개발자들에게 알리거나 다음날 아침에 확인할 수 있게 한다. 이런 빌드를 자동화하기 위해 여러가지 툴을 사용할 수 있는데, 유닉스/리눅스 환경에선 오래 전부터 make를 사용해 왔다. Makefile 이라는 파일에 빌드를 위한 스크립트를 작성한후 make 명령을 실행하면 빌드가 된다. 하지만 make에서 지원하는 기능이 너무 빈약해서 빌드가 복잡할 경우 Makefile에 모든 빌드 과정을 기술해야 하기 때문에 Makefile이 복잡해져서 유지보수가 힘들다는 문제가 있다. 그래서 자바 진영에서는 make를 넘어서는 툴을 만들고자 했고 그래서 2000년 7월 Ant가 등장했다. 그러나 Ant 역시 한계가 있었기 때문에 Ant를 한 단계 더 발전시킨 Maven이 등장했다. 현재 대부분의 오픈소스 자바 프로젝트는 Ant나 Maven 둘 중의 하나를 빌드 도구로 사용하고 있다. 2.1 AntAnt는 구조적으로는 make를 그대로 이어 받았다. build.xml에 빌드 설정을 해두고 ant 명령을 실행하면 빌드 작업이 수행된다. Ant는 자주 하는 작업인 컴파일, 압축, 복사, 메일, SCM 등의 태스크를 미리 갖추어 놓았기 때문에 make보다 훨씬 간단하게 빌드 설정을 할 수 있다. 전체 태스트 목록은 http://ant.apache.org/manual/tasksoverview.html 에서 확인하기 바란다. Ant의 표준 빌드 파일인 build.xml의 예를 보자. build.xml <?xml version="1.0" encoding="euc-kr"?> <project name="Hello Ant" default="dist"> <!-- 프로퍼티를 지정 합니다. --> <property file="build.properties"/> <property name="base.dir" value="."/> <property name="dist.dir" value="dist"/> <property name="build.dir" value="build"/> <property name="src.dir" value="src"/> <property name="jar.file" value="${version}_helloworld.jar"></property> <property name="dist.file" value="${version}_helloworld.zip"/> <target name="prepare"> <tstamp> <format property="DSTAMP" pattern="yyyy.mm.dd" /> <!-- <format property="TSTAMP" pattern="HH:mm" /> --> </tstamp> <echo message="Build Start!! ======> ${DSTAMP}-${TSTAMP}" /> </target> <target name="clean" depends="prepare"> <delete dir="${dist.dir}"/> <delete dir="${build.dir}"/> </target> <!-- 소스 컴파일 --> <target name="compile" depends="clean"> <mkdir dir="${build.dir}"/> <javac deprecation="off" srcdir="${src.dir}" destdir="${build.dir}" listfiles="no" failonerror="true"> <classpath> <pathelement path="${base.dir}/lib" /> <fileset dir="${base.dir}/lib"> <include name="*.jar" /> </fileset> </classpath> </javac> </target> <!-- 빌드 디렉토리에 컴파일이 끝난 클래스를 jar 파일로 묶음 --> <target name="mkjar" depends="compile"> <mkdir dir="${dist.dir}"/> <jar destfile="${dist.dir}/${jar.file}" basedir="${build.dir}" /> </target> <!-- 배포할 라이브러리와 소스등을 배포용 디렉토리로 복사하고 배포용 디렉토리를 zip으로 묶음 --> <!-- jar와 소스, lib 아래의 jar를 배포용 디렉토리에 복사 후 zip으로 묶음 --> <target name="dist" depends="mkjar"> <copy todir="${dist.dir}/lib"> <fileset dir="lib" /> </copy> <copy todir="${dist.dir}/src"> <fileset dir="src" /> </copy> <zip destfile="${DSTAMP}_${TSTAMP}_${dist.file}"> <fileset dir="${dist.dir}/." /> </zip> </target> <!-- HelloWorld 클래스를 호출하여 실행 --> <target name="run"> <java classname="test.HelloAnt"> <classpath> <pathelement location="${dist.dir}/${jar.file}" /> <pathelement path="${base.dir}/lib" /> <fileset dir="${base.dir}/lib"> <include name="*.jar" /> </fileset> </classpath> </java> </target> </project> build.xml을 이용한 실행은 콘솔창에서 ant <targe 이름> 식으로 입력하면 된다. Eclipse 에서는 Ant 과 통합되어 있으므로 다음처럼 실행할 수 있다.
사실 Ant 개발자들은 Ant가 make보다 훨씬 선언적으로 빌드를 정의할 수 있다는 점을 장점으로 내세우지만 이건 사실 javac, copy와 같은 태스크를 미리 자바 클래스로 코딩해 놓았기 때문에 그런 것일 뿐 실제적으로는 Make의 메커니즘과 큰 차이가 없다. 그런 반면 build.xml을 선언적으로 작성할 수 있게 하기 위해 build.xml의 문법에 스크립트적인 요소를 최소한으로 줄였고 또 XML 자체가 프로그래밍이 필요한 부분을 기술하기에는 적합하지 않기 때문에 Ant의 파워는 오히려 make보다 낮아진듯 하다. 그리고 실제로 자바 클래스 컴파일에 파일 몇 개 복사하는 정도라면 아주 간단하게 빌드 파일을 작성할 수 있지만, 복잡해지기 시작하면 build.xml은 점점 이해하기 힘든 코드가 됩니다. 그래서 Ant에서는 build.xml에 주석을 충분히 달아놓을 것을 권고하고 있다. 하지만 복잡해서 주석을 많이 필요로 하는 상황은 좋지 않다. 주석은 Sun 에서도 권장하고 있지 않고, 마틴파울러의 리팩토링에서는 나쁜 냄새라고 얘기한다. 되도록 주석없이 쉽게 이해할 수 있도록 빌드 스크립트를 유지 해야 한다. 하지만 프로젝트 규모가 커지고 기능들의 추가/제거가 많아지면 빌드의 구조도 바뀌고 확장 된다. 결국 Ant도 make보다는 조금 사정이 나아졌지만 본질적으로는 make와 동일한 문제를 갖고 있다. 2.2 Maven 2Maven은 이런 점들을 해결하고 나아가 종합적인 *프로젝트 관리*까지 지원한다. Maven은 현재 버전 2.2까지 나와 있다, Maven 1.x 버전과 2.x 버전간에는 개념을 제외한 파일 호환성이 없으므로, 기존 프로젝트 유지보수 등 특별한 이유가 있지 않는 한 2.x를 사용하길 권장하고 있다. 여기서도 Maven 2를 기준으로 설명한다. (Maven 1 보다 달라진 점은 http://maven.apache.org/maven1.html#changed 에서 보기 바란다.) Project object model(POM)Maven 2 프로젝트의 핵심은 POM(project object model)이다. POM 은 프로젝트에 대한 상세한 설명과 버전 정보, SCM, 의존성, 리소스, 팀 멤버, 구조 등을 포함한다. POM은 프로젝트의 홈디렉토리에 XML 파일(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>com.javaworld.hotels</groupId> <artifactId>HotelDatabase</artifactId> <packaging>war</packaging> <version>1.0-SNAPSHOT</version> <name>Maven 2 Quick Start Archetype</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> Maven 2 디렉토리 구조Maven은 대부분의 것을 표준화 하기 위해 노력하는데, 이것이 장점이다. 다른 Maven 프로젝트에서 일했던 개발자라도 쉽게 구조와 조직에 익숙해 질수 있도록 해준다. 디렉토리 구조나 코딩 규칙 등를 다시 만드느라 시간을 쓸 필요가 없다. Maven 2는 디렉토리 구조를 꼭 지켜주기를 권고하는 데, 이유는 다음과 같다.
Maven 2 의 표준 디렉토리 구조는 다음과 같다. 프로젝트의 홈디렉토리에 pom.xml 이 존재하고 두 개의 하위 디렉토리가 있다. src 에는 모든 source가, target 에는 생성된 모든 것이 들어간다.
src의 하위 폴더는 명확한 목적이 있다.
프로젝트 라이프사이클(Project lifecycles)프로젝트 라이프사이클은 Maven 2 의 핵심영역이다. 대부분의 개발자는 컴파일(compile), 테스트(test), 배포(deploy)등의 빌드 단계(phase) 개념은 알 것이다. Ant에는 이같은 이름의 target 이 있다. Maven 1 에서는 이와 관련되 plug-in 을 직접 호출한다. 예를 들어 소스를 컴파일하려면 java plug-in 을 사용한다. $maven java:compile Maven 2 에서는, 이 개념이 잘 알려지고 잘 정의된 라이프사이클 단계(phase)의 집합으로 표준화 되었다. Maven 2 사용자는 plug-in 호출없이 라이프사이클 단계(phase)를 호출하면 된다. $mvn compile
중요한 라이프사이클 단계는 다음과 같다.
다른 단계에 대해서는 여기 를 참조하기 바란다. Maven 2 의 라이프사이클 단계에 익숙해지면, 어떤 Maven 프로젝트에 가더라도 두렵지 않을 것이다. 라이프사이클의 단계를 호출하면 이전의 단계도 역시 호출한다. 따라서 라이프사이클 단계는 갯수에 제한은 있지만, 이해하기 쉽고, 잘 조직되었으며, Maven 2 프로젝트에 쉽게 적응할 수 있게 도와 준다. Transitive dependenciesMaven 2 에서 눈에 띄는 부분이 transitive dependency 관리이다. Linux의 urpmi 를 사용해 봤다면 어떤 개념인지 알것이다. Maven 1 에서는 필요한 모든 JAR 파일을 직/간접적으로 선언해 줬어야 한다. Hibernate 을 쓰려면 에 어떤 JARs 들이 필요한지 알고 있는가? Maven 2 에서는 이런 걸 몰라도 된다. 그냥 어떤 라이브러리가 필요한지 Maven 에게 알려주기만 하면 알아서 처리해준다. 프로젝트에 Hibernate 을 사용한다고 생각해 보자. 그냥 다음처럼, pom.xml 의 dependencies 섹션에 새로운 dependency 를 추가하기만 하면 된다. <dependency> <groupId>hibernate</groupId> <artifactId>hibernate</artifactId> <version>3.0.3</version> <scope>compile</scope> </dependency> 이게 전부다. Hibernate 3.0.3 을 실행하기 위해 다른 JARs(버전에 따라)를 찾아다닐 필요가 없다. Maven 이 알아서 해 준다. Maven 2 의 dependencies 부분은 Maven 1 과 유사하다. 가장 중요한 차이점은 다음에 설명할 scope 태그이다. Dependency scopes실제 엔터프라이즈 애플리케이션에서 보면, dependencies 있는 모든 것이 배포될 필요는 없다. 어떤 JARs 는 유닛 테스트에만 필요할 수 있고, 또 어떤 것은 애플리케이션 서버에서 런타임 시에만 필요할 수 있다. Maven 2 에서는 dependency scoping 이라는 테크닉을 이용해서 특정 JARs 가 정말 필요할 때만 사용될 수 있게 한다. 필요하지 않을 때는 classpath 에서 제거된다. Maven 은 4가지의 dependency scopes 를 제공한다 :
프로젝트 커뮤니케이션(Project communication)어느 프로젝트에서나 중요한 부분은 내부 커뮤니케이션이다. 만병통치약은 아니지만, 프로젝트 웹사이트에 정보를 집중화시키면 팀내의 가시성을 향상시킬 수 있다. Maven은 프로젝트에 대한 각종 문서가 집약된 사이트를 생성하도록 해준다. 적은 노력으로 수준높은 프로젝트 웹사이트를 재빠르게 만들어 올릴 수 있다. 보통 Maven 사이트는 다음 정보를 만든다 :
Maven 으로 관리되는 프로젝트는 여기 http://maven.apache.org/powered.html 에서 볼수 있다. 3. 토론
참고문헌
문서에 대하여최초작성자 : 김중곤 문서이력 :
|
|
Comments (12)
2월 05, 2006
장회수 says:
언능 언능 해야 할꺼신디? ^^언능 언능 해야 할꺼신디? ^^
2월 06, 2006
Junggon Kim says:
^^.. 휴.. 그래야죠.^^.. 휴.. 그래야죠.
2월 06, 2006
강현수 says:
너두 역시 고생이 많다..^^ 정말 다음 사람들이 큰일났다..ㅎㅎ 수고너두 역시 고생이 많다..^^
정말 다음 사람들이 큰일났다..ㅎㅎ
수고
2월 07, 2006
박재성 says:
와..정말 좋은 자료들 많이 올렸네.. 이렇게 처음부터 잘하면 다음에 준비할 사람들 무지 부담되겠는걸.. 이번 기수에 참가하는 사람들도 너무 ...와..정말 좋은 자료들 많이 올렸네..
이렇게 처음부터 잘하면 다음에 준비할 사람들 무지 부담되겠는걸..
이번 기수에 참가하는 사람들도 너무 열정적인 듯 싶다..
2월 07, 2006
김현기 says:
멋지다!!!!멋지다!!!!
2월 07, 2006
Jang Jooran says:
오~~ 대단해요~!! ^^오~~ 대단해요~!! ^^
2월 07, 2006
Ryu Sung Hee says:
헉.. 너무 잘 정리하시는거 아니에요.. 뒷 사람들 부담되게스리요...ㅋㅋ헉.. 너무 잘 정리하시는거 아니에요..
뒷 사람들 부담되게스리요...ㅋㅋ
2월 07, 2006
장회수 says:
^^ 베리~굿!잡!^^ 베리~굿!잡!
2월 08, 2006
김기훈 says:
엄청 부담되네요... ㅠ.ㅠ엄청 부담되네요... ㅠ.ㅠ
2월 08, 2006
강윤기 says:
Good^^Good^^
2월 09, 2006
이명섭 says:
자료 고맙고 오늘 수고했네..자료 고맙고 오늘 수고했네..
2월 11, 2006
김기훈 says:
고생 많으셨습니다. ^^고생 많으셨습니다. ^^