MAVEN 메이븐

MAVEN 메이븐

2012. 7. 13. 12:58ㆍ99. 정리전 - IT/29. IT 잡동지식

출처 : http://www.javajigi.net/display/IDE/Maven+Getting+Started

MAVEN .docx

Maven 기본 정보

Maven Site : http://maven.apache.org
Maven Document Index : http://maven.apache.org/guides/index.html

자바지기가 생각하는 Maven 스터디 순서

Getting Started in 5 Minutes 문서 또는 Getting Started in 30 Minutes 문서를 통하여 Maven이 어떤 방식으로 동작하는지 실행해본다.
jar 프로젝트를 생성하고 관리하는 방법에 대하여 실행해본다.
war 프로젝트를 생성하고 관리하는 방법에 대하여 실행해본다.
각 프로젝트들간의 의존관계를 Maven을 통하여 관리하는 방법에 대하여 스터디한다.
Article: Setting up a Maven repository with Artifactory 문서를 이용하여 Maven Repository에 대한 Mirror 사이트를 만들고 Local Repository를 운영하는 방법에 대하여 분석한다.
Maven을 이용할 때의 개발 프로세스를 어떻게 가져갈 수 있는지에 대하여 스터디한다.
Maven의 세부 기능을 좀 더 구체적으로 분석하면서 프로젝트에 활용할 수 있는 방법들을 찾는다.

Maven 설치 과정

http://maven.apache.org에서 Maven 최신 버전을 다운받는다. 이 문서에서는 maven 2.0.7 버전을 사용하였다.
다운 받은 maven-2.0.7-bin.zip 파일의 압축을 푼 다음 시스템 환경 변수에 MAVEN_HOME을 추가한다.
시스템 환경 변수 PATH에 MAVEN_HOME/bin을 추가한다.
Prompt에서 "mvn -version"을 실행하여 Maven이 정상적으로 설치되었는지 확인할 수 있다.

최초 프로젝트 생성

최초의 Maven 프로젝트를 생성하기 위해서 Maven의 archetype 매커니즘을 사용할 수 있다.

Archetype은 "다른 비슷한 것을 생성할 수 있는 원래의 패턴 또는 모델"로 정의된다. Maven에서는 Archetype은 프로젝트의 템플릿 역할을 해서 사용자가 입력한 정보를 조합해서 새로운 Maven 프로젝트를 생성한다. Archetype에 대한 자세한 사항은 "Archetype 소개" 문서를 참고하자.

Maven은 생성하려는 프로젝트의 성격에 따라서 여러개의 Archetype을 제공하고 있다.

jar 파일 기반의 애플리케이션을 개발하고자 한다면 다음과 같은 방법으로 Maven 기반의 Template 프로젝트를 생성하는 것이 가능하다.

mvn archetype:create -DgroupId=net.javajigi -DartifactId=mysample

웹 애플리케이션을 개발하고자 한다면 다음과 같은 Archetype을 이용하여 Template 프로젝트를 생성할 수 있다.

mvn archetype:create -DgroupId=net.javajigi -DartifactId=mywebapp -DarchetypeArtifactId=maven-archetype-webapp

Template 프로젝트를 생성하고 싶은 디렉토리로 이동한 다음 위 Archetype을 실행할 경우 다음과 같은 Template 프로젝트가 생성된다.

Local Repository 경로 변경

Maven Repository의 디폴트 경로는 User Home/.m2/repository 이다. 디폴트 경로를 변경하고자 한다면 다음과 같이 변경하는 것이 가능하다.
MAVEN_HOME/conf 디렉토리 하위에 settings.xml 파일을 열어보면 localRepository 엘리먼트가 주석처리 되어 있는 것을 확인할 수 있다.
localRepository 엘리먼트를 다음과 같이 설정함으로서 Local Repository의 경로를 다음과 같이 수정함으로서 변경하는 것이 가능하다.

<localRepository>D:/Repositories/MavenRepository</localRepository>

나만의 Maven archetype 생성하기

참고 문서 :

Guide to Creating Archetypes

Maven Book

Maven 빌드시 test 과정을 skip하고 싶다면..

테스트 코드가 있으나 전체 테스트 코드가 성공하지 못할 경우에 유용하게 사용할 수 있을 것으로 생각.
Add the parameter -Dmaven.test.skip=true in the command line

Maven 설치 및 최초 프로젝트 생성

Maven 설치

Maven을 설치하는 과정은 다음과 같은 과정을 통하여 쉽게 설치할 수 있다.

http://maven.apache.org에서 Maven 최신 버전을 다운받는다. 이 문서에서는 maven 2.0.7 버전을 사용하였다.
다운 받은 maven-2.0.7-bin.zip 파일의 압축을 푼 다음 시스템 환경 변수에 MAVEN_HOME을 추가한다.
시스템 환경 변수 PATH에 MAVEN_HOME/bin을 추가한다.
Prompt에서 "mvn -version"을 실행하여 Maven이 정상적으로 설치되었는지 확인할 수 있다.

Maven 기반의 Template Java 프로젝트 생성

Maven은 각 프로젝트의 성격에 맞도록 Template 프로젝트를 제공하고 있다. Maven을 이용하여 Template 프로젝트는 쉽게 생성할 수 있다. Maven의 이 같은 기능을 archetype이라고 한다. Archetype에 대한 자세한 내용은 Archetype 소개 문서를 참고하기 바란다.

Prompt에서 다음과 같은 명령어를 실행하여 Template 프로젝트를 생성할 수 있다.

mvn archetype:create -DgroupId=net.javajigi -DartifactId=mysample

위 명령어에서 groupId와 artifactId는 프로젝트를 생성하는 개발자가 임의로 변경하는 것이 가능하다. groupId와 artifactId에 대한 자세한 내용은 추후 강좌에서 다루도록 하겠다.

위 명령어에 의하여 생성된 Template 프로젝트는 jar 파일로 압축되어 Maven Repository에 의하여 관리되게 된다.

Maven 기반의 Template Webapp 프로젝트 생성

Maven은 웹 애플리케이션 개발을 위한 Template Archetype을 제공한다. 웹 애플리케이션 프로젝트를 생성하기 위한 명령어는 다음과 같다.

mvn archetype:create -DgroupId=net.javajigi -DartifactId=mywebapp -DarchetypeArtifactId=maven-archetype-webapp

위 명령어에 의하여 생성된 Template 프로젝트는 war 파일로 압축되어 Maven Repository에 의하여 관리된다.

위 명령어를 실행하여 생성된 Template 프로젝트의 디렉토리 구조는 다음과 같다.

Maven 강좌 2 - Maven 개요, 잇점, POM 설정 파일 기본

Maven 이란?

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

Builds
Documentation
Reporting
Dependencies
SCMs
Releases
Distribution

Ant 를 이용하여 지금까지 위 작업 중의 일부(Builds, Reporting 등) 작업을 진행해 왔지만 일관된 가이드안이 없는 상태였기 때문에 프로젝트를 진행할 때마다 대부분의 작업을 반복해야 했다. 그러나 Maven의 경우에는 프로젝트 관리를 위하여 필요한 모든 작업을 추상화하여 툴이 지원하도록 구현했다.

Ant를 사용하다 Maven을 처음 시작하는 개발자들은 Maven의 제약사항에 거부감을 느낄 수 있다. Ant만큼 자유도가 높지는 않지만(물론 Ant의 빌드 스크립트와 통합하는 것도 가능하다.) Ant를 사용하면서 반복해야 했던 많은 작업들을 줄여준다. 이 같은 효과는 모든 프로젝트를 일관된 구조로 관리, 배포, 운영하는 것이 가능하기 때문에 프로젝트의 복잡도가 증가하고 있는 최근에는 적합한 툴이라 생각한다.

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

Maven을 사용하면서 얻게 되는 잇점은 Benefits of using Maven 문서를 통하여 확인할 수 있다.
필자 또한 Maven 사용할 경우 너무 많은 잇점을 얻을 수 있을거 같아 모두 정리하기 힘들거 같다. 그래도 정리한다면 다음 항목을 최우선적으로 이야기하고 싶다.

편리한 Dependent Library 관리 기능 - Dependency Management
모든 프로젝트의 빌드 프로세스를 일관되게 가져갈 수 있다는 것
Maven이 제공하는 많은 플러그인의 활용이 가능하다는 것. 특히 Maven 프로젝트를 Eclipse 기반 프로젝트로 쉽게 변환이 가능한 기능
신규 프로젝트 세팅을 정말 쉽고 빠르게 진행할 수 있다. Maven의 archetype 기능은 정말 만족할 만하다.

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">

<groupId>net.javajigi</groupId>

<artifactId>mysample</artifactId>

<version>1.0-SNAPSHOT</version>

<name>mysample</name>

<url>http://maven.apache.org</url>

<groupId>junit</groupId>

<artifactId>junit</artifactId>

</dependency>

</dependencies>

</project>

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

Maven 을 이용할 경우 얻게 되는 큰 잇점 중의 하나는 Dependency Management 기능이다. 위 pom.xml 파일에서 <dependencies/> 엘리먼트가 Dependency Management 기능의 핵심이라고 할 수 있다. Dependency Management 기능에 대해서는 다음 기회에 다루도록 하겠다.

Maven 강좌 3 - Maven 디폴트 디렉토리 구조 및 사용할 수 있는 Goals

Maven 디폴트 디렉토리 구조

Maven의 archetype 기능을 이용하여 생성된 프로젝트의 디렉토리 구조를 통하여 Maven의 디폴트 디렉토리 구조를 살펴보도록 하자.

자바 애플리케이션 프로젝트의 디폴트 디렉토리 구조는 다음과 같다.

Maven의 디폴트 자바 소스 디렉토리는 src/main/java 이다. 구현 소스에 대한 테스트 디렉토리는 src/test/java 이다. Maven은 디폴트로 구현 소스와 테스트 소스를 분리하여 개발이 가능하도록 지원하고 있다.

위 와 같은 구조로 생성한 다음 프로젝트를 빌드할 경우 target 디렉토리에 컴파일된 클래스가 위치하게 된다. src/main/java 디렉토리의 구현 코드는 target/classes에 컴파일 되며, src/main/test 디렉토리의 테스트 코드는 target/test-classes에 컴파일 된다. Maven을 이용하여 빌드할 경우 구현 코드와 테스크 코드를 분명하게 분리하여 관리한다는 것을 확인할 수 있다. 빌드를 통하여 최종적으로 생성된 jar 파일은 mysample에 위치하게 되며, target/classes의 구현 코드만 jar로 압축되게 된다.

archetype을 이용하여 웹 애플리케이션을 생성하면 디폴트 디렉토리 구조는 다음과 같다.

웹 애플리케이션의 웹 리소스에 대한 디폴트 디렉토리는 src/main/webapp 이다. 빌드 과정은 자바 애플리케이션과 같다. 하나의 프로젝트에서 웹 리소스와 자바 소스를 같이 관리할 경우에는 위 두개의 프로젝트를 합쳐 놓은 구조로 관리하면 된다.

Maven에서 디폴트로 사용할 수 있는 Goals

Ant 는 프로젝트를 빌드하기 위하여 모든 target을 프로젝트를 생성할 때마다 새롭게 생성해야 한다. 그러나 Maven의 경우 디폴트 디렉토리를 사용하고 있다면 Maven에서 제공하고 있는 디폴트 Goals을 이용하여 빌드하는 것이 가능하다. Maven의 Goal은 Ant의 Target과 같은 개념으로 생각하면 된다.

처음 살펴볼 Goal은 구현 코드를 컴파일 위한 compile goal이다. Archetype을 이용하여 디폴트로 생성한 디렉토리 하위로 이동한 후 다음과 같은 명령어를 통하여 컴파일이 가능하다.

mvn compile

위 Goal은 src/main/java 디렉토리에 위치한 구현 코드만 컴파일 한다. 만약 테스트 코드를 컴파일 하고자 한다면 test-compile Goal을 이용하면 된다.

mvn test-compile

test-compile Goal은 compile Goal에 의존관계에 있다. 따라서 test-compile Goal을 실행할 경우 compile Goal이 먼저 실행된다. test-compile을 실행했을 때의 maven 로그를 살펴보면 다음과 같다.

테스트 코드를 이용하여 구현 코드를 테스트하기 위한 방법은 test Goal을 이용하여 가능하다.

mvn test

test Goal은 target/test-classes에 위치한 junit 단위 테스트 클래스를 이용하여 구현 클래스를 테스트하고 그에 따른 결과 target/surefire-reports 디렉토리에 생성한다.

컴파일한 구현 코드를 jar, war로 압축하는 Goal은 package이다.

mvn package

package Goal을 실행하면 compile, test-compile, test, package 순으로 Goal이 실행된 다음 jar, war 파일이 target 디렉토리 하위에 생성된다. 생성되는 jar, war의 명명 규칙은 artifactId-version.packaging이 된다.

예를 들어 pom.xml 설정 파일이 다음과 같이 설정되어 있다고 하자.

<artifactId>mysample</artifactId>

<version>1.0-SNAPSHOT</version>

위 설정 파일에 의하여 생성되는 압축 파일은 mysample-1.0-SNAPSHOT.jar 이다.

마지막으로 살펴볼 Goal은 압축한 jar 파일을 Local Repository에 등록하는 것이다. Local Repository와 Dependency에 대한 자세한 내용은 다음 강좌에서 다루도록 하겠다.

mvn install

install Goal은 package Goal에 의하여 생성된 jar, war 파일을 Local Repository에 등록한다.

다른 개발자들과 jar, war파일을 공유하기 위하여 Local에서 압축한 jar, war을 Remote Repository에 등록할 필요가 있다. 이 작업을 위해서 Maven이 지원하는 Goal은 deploy이다.

mvn deploy

deploy Goal은 jar, war 파일을 외부 Remote Repository에 등록하는 역할을 한다.

지금까지 살펴본 Goal의 의존관계를 살펴보면 다음과 같다.

· compile

· test-compile

· test

· package

· install

· deploy

순이다.

Maven 강좌 4 - Maven을 이용하여 Dependency 라이브러리 관리 방법

AS-IS Dependency 라이브러리 관리 방법

애플리케이션을 개발할 때 지금까지 외부 라이브러리를 관리하는 방법은 다음과 같은 문제점을 가지고 있다.

라이브러리의 추가 및 버전 변경이 불편하다.

버전 관리 시스템(CVS, SVN)을 이용하여 공유할 파일 크기가 커진다.

현재 사용하고 있는 라이브러리의 버전을 파악하기 힘들다.

컴파일, 배포, 테스트할 때만 사용하는 라이브러리를 분리하기 힘들다.

WTP의 경우 자동 클래스 패스 기능이 너무 느리다.

예를 들어 Spring 프레임워크 기반으로 애플리케이션을 개발할 때 Spring 프레임워크의 버전을 변경하고자 한다면 다음과 같은 사이클을 통하여 변경할 수 있다.

위 그림을 통해서 확인할 수 있듯이 하나의 라이브러리를 관리하기 위하여 복잡한 과정을 통하여 가능하다. 하나의 애플리케이션을 개발하기 위하여 사용하는 외부 라이브러리가 점점 더 많아지고 복잡해지는 상황에서 현재와 같은 라이브러리 관리 방법은 한계를 가질 수 밖에 없다.

하나의 애플리케이션을 개발할 때 외부 라이브러리의 의존도가 어떻게 변화하고 있는지 살펴보면 다음과 같다.

Maven의 Dependency 기능은 지금까지 외부 라이브러리를 관리할 때의 많은 문제점을 해결하는 것이 가능하다. 필자가 Maven을 사용하면서 가장 만족하는 기능이 바로 이 Dependency 관리 기능이다.

Maven의 Dependency 관리 기능

Maven의 Dependency 관리 기능은 의외로 단순하다. Maven 강좌 2 의 pom.xml 파일을 살펴볼 때 다음 강좌로 넘겨버렸던 dependencies 엘리먼트가 그 핵심이다. 먼저 pom.xml 파일에서 외부 라이브러리와의 의존관계를 가지기 위하여 다음과 같이 설정하는 것이 가능하다.

<groupId>junit</groupId>

<artifactId>junit</artifactId>

</dependency>

</dependencies>

<dependencies> 엘리먼트가 의미하듯이 이 엘리먼트 하위에는 여러개의 <dependency> 엘리먼트를 가질 수 있다.

pom.xml 파일을 위와 같이 설정한 다음 "mvn compile" 명령을 실행하면 junit 3.8.1 버전의 jar 파일이 자동으로 로컬에 다운 받아진다. jar 파일이 관리되는 원칙은 다음과 같다.

Maven Local Repository의 변경없이 디폴트 디렉토리를 사용하고 있다면 USER_HOME/.m2/repository(윈도우 시스템의 경우 USER_HOME은 C:\Documents and Settings\UserId 가 된다.)디렉토리에 모든 Dependency 라이브러리가 다운 받아진다. 위와 같이 pom.xml 파일을 설정한다면 다음 위치에 jar 파일이 다운 받아진다.

USER_HOME/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar

Maven이 Dependency 라이브러리를 관리하는 규칙은 다음과 같다.

USER_HOME/.m2/repository/groupId/artifactId/artifactId-version.jar

Maven에서 Dependency 라이브러리가 버전을 변경하고자 한다면 pom.xml 파일에서 버전 번호만 변경하면 Dependency 라이브러리에 대한 버전이 변경된다.

예를 들어 junit 라이브러리를 4.3으로 변경하고자 한다면 다음과 같이 설정할 수 있다.

<groupId>junit</groupId>

<artifactId>junit</artifactId>

</dependency>

</dependencies>

이와 같이 하나의 라이브러리에 대한 버전을 변경할 경우 Local Maven Repository의 디렉토리 구조는 다음과 같다.

Maven의 중앙 Repository

Maven 이 위와 같이 Dependency 라이브러리를 관리할 수 있는 이유는 Maven이 모든 오픈 소스 라이브러리에 대하여 중앙 Repository를 가지고 있기 때문이다. pom.xml 파일에 특별히 Repository를 설정할지 않을 경우 Maven은 http://www.ibiblio.org/maven/ 이다. http://www.ibiblio.org/maven/ 에 접근해보면 Maven에서 사용할 수 있는 모든 라이브러리를 찾을 수 있다.

http://www.ibiblio.org/maven/에서 관리하는 라이브러리의 수가 한 두개가 아니다. 외부 라이브러리를 추가할 때 좀 더 쉬운 방법은 검색을 지원하는 http://mvnrepository.com/ 을 이용하면 편하다.

예를 들어 Maven Repository에서 관리하고 있는 Spring 프레임워크에 대한 라이브러리 정보를 찾고자 한다면 먼저 http://mvnrepository.com/ 에 접근한다. 그 다음 springframework로 검색하면 다음과 같은 결과 화면을 얻을 수 있다.

위 결과 화면에서 추가하고자하는 Spring 프레임워크 모듈을 선택한다.

필자는 Spring 전체 모듈을 추가할 예정이므로 org.springframework >> spring을 선택한 다음 사용하고자 하는 버전을 선택하면 다음과 같이 pom.xml에 추가할 수 있는 <dependency> 엘리먼트 정보를 찾을 수 있다.

위에서 구한 <dependency> 엘리먼트를 추가하게 되면 spring 프레임워크 라이브러가 Local Repository에 자동으로 다운되어 Maven이 빌드할 때 사용되게 된다. 클래스패스에 하는 추가적인 작업을 할 필요도 없다. Maven은 pom.xml 설정 파일의 <dependency> 엘리먼트 정보를 이용하여 Local Repository에서 해당 jar 파일을 찾게 되는 것이다.

Local Repository 경로 변경

Maven을 사용할 때 아무런 세팅을 하지 않는다면 위에서 설명한 바와 같이 Local Repository의 경로는 디폴트로 USER_HOME/.m2/repository가 된다.
만약 Local Repository의 경로를 바꾸고자 한다면 다음과 같은 방법으로 변경하는 것이 가능하다.

MAVEN_HOME/conf 디렉토리 하위에 settings.xml 파일을 열어보면 localRepository 엘리먼트가 주석처리 되어 있는 것을 확인할 수 있다. 주석처리되어 있는 localRepository를 다음과 같이 변경해 주면 된다.

<localRepository>D:/Repositories/MavenRepository</localRepository>

Dependency 라이브러리의 Scope

Maven은 사용하고 있는 라이브러리의 성격에 따라 Scope를 지정하는 것이 가능하다. 예를 들어 junit의 경우 단순히 테스트를 위해서만 사용되고 실제 배포될 때는 필요없는 라이브러리이다.

compile : scope를 설정할지 않았을 때의 디폴트 scope이다. 컴파일 시에도 사용되며, 배포시에도 같이 배포되어야 하는 라이브러리이다.
provided : JDK가 컨테이너에 의하여 제공되는 라이브러리이다. 예를 들어 servlet.jar의 경우 Servlet 컨테이너에 의하여 제공되기 때문에 이 scope를 사용한다.
runtime : 이 scope는 말 그대로 컴파일 시에는 사용되지 않지만 애플리케이션을 실행할 때 사용되는 라이브러리일 경우 설정한다.
test : 테스트를 위해서만 사용하는 라이브러리이다.
system : 이 scope는 provided와 비슷하다. 단지 우리가 직접 jar 파일을 제공해야 한다. 따라서 이 scope의 jar 파일은 repository에서 관리되지 않을 수도 있다.

지금까지 Maven이 Dependency 라이브러리를 관리하는 방법에 대하여 살펴보았다. Maven을 사용하면서 가장 큰 도움을 얻을 수 있는 부분이며, 정말 유용한 기능이라고 생각된다. 현재 Ant를 사용하고 있다면 Antlib을 사용해서 Maven의 Dependency 기능을 이용하는 것이 가능하다. 그러므로 외부 라이브러리 관리에 불편함을 겪고 있는 개발자라면 Maven의 Dependency 기능을 꼭 사용해보기 바란다.

다음 강좌는 Maven 기반의 프로젝트를 Eclipse 프로젝트로 변환하고 Maven IDE를 이용하여 Maven 설정 파일을 관리할 수 있는 방법에 대하여 살펴보도록 하겠다.

Maven 강좌 5 - Maven 기반의 Eclipse 프로젝트 생성 및 활용

Maven의 Eclipse 플러그인 활용하기

Maven 기반으로 개발되어 있는 프로젝트를 Eclipse 프로젝트로 변환하는 작업은 간단하다. Maven의 Eclipse 플러그인을 이용하여 쉽게 Eclipse 프로젝트로 만들 수 있다.

프 로젝트 디렉토리로 이동한 다음 "mvn eclipse:eclipse" 명령어를 실행하면 Eclipse 기반 프로젝트로 변경된다. Eclipse 프로젝트에 필요한 .project, .classpath 파일들이 자동적으로 생성된다. .classpath 파일을 열어보면 pom.xml 파일에서 의존관계에 있는 모든 라이브러리들이 자동적으로 추가되어 있는 것을 확인할 수 있다.

예를 들어 pom.xml 파일이 다음과 같이 설정되어 있다고 가정하다.

<groupId>junit</groupId>

<artifactId>junit</artifactId>

</dependency>

위와 같이 junit 라이브러리와 dependency 설정이 되어 있다면 이 정보는 .classpath에 다음과 같이 추가된다.

<classpathentry kind="var"

path="M2_REPO/junit/junit/3.8.1/junit-3.8.1.jar"

sourcepath="M2_REPO/junit/junit/3.8.1/junit-3.8.1-sources.jar"/>

.classpath에서 눈여겨 볼 부분은 sourcepath가 자동적으로 설정된다는 것이다. Maven은 라이브러리를 배포할 때 자바 소스까지 분리해서 배포하는 것이 가능하도록 지원하다. Eclipse 기반으로 애플리케이션을 개발할 때 F3나 디버깅을 많이 이용할 것이다. 이 기능들을 이용할 때 불편했던 점은 외부 라이브러리에 대한 소스 코드가 존재하지 않아 소스 코드를 분석하는데 한계가 있었던 것이 사실이다. 그러나 Maven을 이용할 경우 이 같은 단점을 보완할 수 있다. Maven을 이용하여 소스 코드를 배포하는 모든 라이브러리의 소스 코드는 자동적으로 Local Repository에 다운받아져 위와 같이 설정이 가능하기 때문에 Eclipse에서 외부 라이브러리 소스코드에 접근하기 용이해진다.

디폴트 pom.xml을 사용할 경우 자바 프로젝트가 생성된다. 만약 웹 애플리케이션을 생성하기 위하여 WTP 기반으로 애플리케이션을 개발하고자 한다면 pom.xml에 다음과 같은 설정을 추가함으로서 해결할 수 있다.

<artifactId>maven-eclipse-plugin</artifactId>

</configuration>

</plugin>

</plugins>

Maven의 Eclipse 플러그인에 대한 설정에 WTP에 대한 설정을 추가하고 "mvn eclipse:eclipse" 명령어를 실행하면 WTP 기반으로 프로젝트를 진행할 수 있도록 Eclipse 프로젝트가 생성된다.

만약 Spring IDE를 사용할 경우 .project 파일에 Spring IDE Nature를 추가하는 것도 가능하다.

<artifactId>maven-eclipse-plugin</artifactId>

org.springframework.ide.eclipse.core.springnature

</projectnature>

</additionalProjectnatures>

org.springframework.ide.eclipse.core.springbuilder

</buildcommand>

</additionalBuildcommands>

</configuration>

</plugin>

</plugins>

위와 같이 설정한 다음 생성된 .project 파일을 열어보면 다음과 같다.

<name>myarchetype</name>

<name>org.eclipse.jdt.core.javabuilder</name>

</buildCommand>

<name>org.eclipse.wst.common.project.facet.core.builder</name>

</buildCommand>

<name>org.eclipse.wst.validation.validationbuilder</name>

</buildCommand>

<name>org.springframework.ide.eclipse.core.springbuilder</name>

</buildCommand>

</buildSpec>

<nature>org.eclipse.wst.common.project.facet.core.nature</nature>

<nature>org.eclipse.jdt.core.javanature</nature>

<nature>org.eclipse.wst.common.modulecore.ModuleCoreNature</nature>

<nature>org.eclipse.jem.workbench.JavaEMFNature</nature>

<nature>org.springframework.ide.eclipse.core.springnature</nature>

</natures>

</projectDescription>

생성된 Eclipse 프로젝트 Import 하기

Maven 을 이용하여 생성한 프로젝트를 import 하는 방법은 간단하다. 가능하면 현재 Eclipse가 사용하고 있는 Workspace 아래에 프로젝트를 생성하는 것이 좋다. Workspace 아래에 프로젝트를 생성한 다음 Eclipse의 import || General || Existing Projects into Workspace를 이용하여 Import 한다.

Maven을 이용하여 생성한 프로젝트를 import 하면 빌드 에러가 발생할 것이다. 그 이유는 앞의 .classpath에서 확인할 수 있듯이 M2_REPO가 classpath variable에 추가되어 있지 않기 때문이다. Window || Preferences || Java || Build Path || Classpath Variables로 이동한 다음 M2_REPO를 추가할 수 있다.

위와 같은 간단한 작업을 WTP 기반의 Eclipse 프로젝트를 생성하는 것이 가능하다. Maven의 디폴트 디렉토리 구조는 디폴트 웹 애플리케이션 디렉토리 구조가 아니다. 그럼에도 불구하고 WTP를 이용하여 Maven 프로젝트를 테스트할 수 있는 이유는 Maven에 의하여 자동적으로 생성되는 설정파일을 통하여 확인할 수 있다.

WTP의 모든 설정 파일은 .settings 디렉토리에 생성된다. .settings 디렉토리 하위의 org.eclipse.wst.common.component 파일을 열어보면 다음과 같다.

<project-modules id="moduleCoreId" project-version="1.5.0">

<wb-module deploy-name="myarchetype">

<wb-resource deploy-path="/" source-path="src/main/webapp" />

<dependent-module deploy-path="/WEB-INF/lib"

handle="module:/classpath/var/M2_REPO/log4j/log4j/1.2.13/log4j-1.2.13.jar">

<dependency-type>uses</dependency-type>

</dependent-module>

<wb-resource deploy-path="/WEB-INF/classes"

source-path="src/main/java" />

<wb-resource deploy-path="/WEB-INF/classes"

source-path="src/main/resources" />

</wb-module>

</project-modules>

org.eclipse.wst.common.component 파일을 보면 WTP가 실행할 때 접근해야 할 리소스와 클래스 파일들의 위치가 Maven 디폴트 디렉토리로 설정되어 있는 것을 확인할 수 있다. 또한 의존관계에 있는 라이브러리까지 추가되어 있는 것을 확인할 수 있다. 그러므로 추가적인 설정 없이 WTP 기반으로 테스트 및 개발이 가능하게 된다.

지금까지 애플리케이션을 개발하면서 프로젝트를 처음 생성하고 개발자들간의 개발환경을 세팅하는데 상당히 많은 시간을 소비해왔다. 그러나 Maven의 Eclipse 플러그인 기능은 개발자들의 개발 환경을 쉽게 세팅할 수 있도록 지원함으로서 개발의 효율성을 가져올 수 있다.

다음 강좌에서는 Remote Repository만을 활용할 때의 단점에 대해서 살펴본 다음 Local Repsistory의 필요성 및 환경 세팅하는 방법에 대하여 살펴보도록 하겠다. Local Repository로 활용할 툴은 Artifactory를 사용할 예정이다.

Maven 강좌 6 - Artifactory를 이용하여 Maven Repository 세팅하기

사내 Maven Repository의 필요성

Maven을 기반으로한 라이브러리 관리 방식은 Maven Repository에서 라이브러리를 관리하고 이를 Local Repository에 다운로드하는 방식이다. Maven Repository에서 관리하고 있는 라이브러리의 수는 너무 많아서 그 수를 헤아리기조차 힘들다. 그러나 Maven Repository가 우리가 필요로하는 모든 라이브러리를 모두 관리할 수는 없는 것이다.
예를 들어 사내에서 개발하여 배포되는 라이브러리는 범용적으로 사용되는 라이브러리가 아니기 때문에 Maven Repository에 관리하기 힘들다. 이외에도 사내 Maven Repository를 가질 경우 많은 잇점이 있다.

Reduced likelihood of version conflicts
Less manual intervention required for doing a build first time
A single central reference repository of all dependent software libraries rather than several independent local libraries
It is quicker to do a clean build when using an internal repository as maven artifacts are retrieved from a server on the intranet rather than the ibiblio server on the internet

위 내용은 Setting Up a Maven Repository문서에서 이야기하고 있는 사내 Repository를 설치할 경우의 장점이다.

사내 Repository를 가질 때와 그렇지 않을 때의 개발 환경을 살펴보면 다음과 같다.

위 그림은 사내 Maven Repository를 가지지 않을 때의 개발 환경이다.

위 그림은 사내 Maven Repository를 가질 때의 개발 환경이다.

Artifactory를 이용한 사내 Maven Repository 설치하기

Artifactory는 오픈 소스로 사내 Maven Repository로 설치해서 사용하기 좋다. Setting Up a Maven Repository문서를 보면 사내 Maven Repository로 사용할 수 있는 툴들을 비교한 자료를 볼 수 있다.

Artifactory 설치에 대한 이 강좌의 모든 내용 또한 Setting Up a Maven Repository문서를 참고해서 작성했다.

http://www.jfrog.org/sites/artifactory/latest/ 에서 Artifactory 최신 버전을 다운 받는다.
JDK 5.x 이상을 설치한다.
Tomcat 5.5 이상을 설치한다.

Artifactory는 웹 애플리케이션으로 구현되어 있다. 다운 받은 Artifactory 최신 버전의 압축을 풀어보면 webapps 디렉토리 아래에 artifactory.war 파일을 찾을 수 있다.

이 artifactory.war 파일을 TOMCAT_HOME/webapps 디렉토리 아래에 복사한다. TOMCAT_HOME/bin 디렉토리 아래에 catalina.bat 파일을 열어 JAVA_OPTS에 다음 항목을 추가한다.

JAVA_OPTS = -Dartifactory.home=D:\Devs\Tools\artifactory-1.2.2

TOMCAT 에 추가하지 않고 시스템 환경 변수에 추가해도 된다. artifactory.home에 설정해야 하는 디렉토리는 Artifactory 최신 버전의 압축을 푼 디렉토리이다. Artifactory는 Artifactory 설치 디렉토리 하위의 data 디렉토리를 이용하기 때문에 위 항목을 반드시 추가해야 한다.

Artifactory 설치는 위 과정만 거치면 된다. Artifactory는 간단하게 설치할 수 있다.

Artifactory 사용하기

라이브러리를 분리해서 관리하기 위하여 Artifactory를 다음과 같이 설정하는 것이 가능하다.

<ARTIFACTORY_INSTALLATION_FOLDER>/etc/artifactory.config.xml 파일을 만든 후 다음과 같이 설정할 수 있다.

<?xml version="1.0" encoding="UTF-8"?>

<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

        xmlns="http://artifactory.jfrog.org/xsd/1.0.0"

        xsi:schemaLocation="http://artifactory.jfrog.org/xsd/1.0.0

        http://www.jfrog.org/xsd/artifactory-v1_0_0.xsd">

    <!-- Backup every 12 hours -->

    <!--<backupCronExp>0 0 /12 * * ?</backupCronExp>-->

    <localRepositories>

      <localRepository>

          <key>private-internal-repository</key>

          <description>Private internal repository</description>

          <handleReleases>true</handleReleases>

          <handleSnapshots>true</handleSnapshots>

      </localRepository>

      <localRepository>

          <key>3rd-party</key>

          <description>3rd party jars added manually</description>

          <handleReleases>true</handleReleases>

          <handleSnapshots>false</handleSnapshots>

      </localRepository>

    </localRepositories>

    <remoteRepositories>

      <remoteRepository>

          <key>ibiblio</key>

          <handleReleases>true</handleReleases>

          <handleSnapshots>false</handleSnapshots>

          <excludesPattern>org/artifactory/**,org/jfrog/**</excludesPattern>

          <url>http://repo1.maven.org/maven2</url>

      </remoteRepository>

    </remoteRepositories>

</config>

위 설정은 라이브러리를 3가지 용도로 나뉘어 관리하겠다는 것이다. 중앙 Maven Repository의 Mirror 역할을 하게 될 Repository(ibiblio), 3rd party 라이브러리를 관리하기 위한 Repository(3rd-party), 사내에서 개발되는 라이브러리를 관리하기 위한 Repository(private-internal-repository)로 나누고 있다. 물론 사내 정책에 따라 더 많은 Repository를 관리하는 것 또한 가능하다.

위와 같이 설정한 다음 Tomcat을 시작한 다음 Artifactory에 접근할 수 있다.

http://localhost:8080/artifactory로 접근하면 Artifactory 로그인 화면에 접근할 수 있다. 필자는 host파일에 다음과 같이 설정하여 사용하고 있다.

repository.javajigi.net 127.0.0.1

Artifactory의 디폴트 사용자는 UserName : admin, Password : password 를 이용하여 로그인할 수 있다.

Artifactory 메인 페이지는 위와 같다.

좌측 메뉴에서 Browse the repository를 선택하면 다음 화면과 같다. 앞에서 설정한 3개의 Repository가 생성되어 있는 것을 볼 수 있다.

마지막으로 설정할 부분은 Maven 빌드툴이 새로 설치한 Artifactory를 사용할 수 있도록 설정하는 것이다. 사내 Maven Repository를 사용하도록 설정하는 방법은 다음과 같다.

USER_HOME/.m2/settings.xml 파일을 다음과 같이 설정한다. 필자의 경우 C:\Documents and Settings\javajigi\.m2\settings.xml 파일을 다음과 같이 설정했다.

<settings 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/xsd/settings-1.0.0.xsd">

<tomcat6x.home>D:/Devs/Servers/Tomcat-6.0.14</tomcat6x.home>

</properties>

<id>central</id>

<url>http://repository.javajigi.net:8080/artifactory/repo</url>

<enabled>false</enabled>

</snapshots>

</repository>

<id>snapshots</id>

<url>http://repository.javajigi.net:8080/artifactory/repo</url>

<enabled>false</enabled>

</releases>

</repository>

</repositories>

<id>central</id>

<url>http://repository.javajigi.net:8080/artifactory/repo</url>

<enabled>false</enabled>

</snapshots>

</pluginRepository>

<id>snapshots</id>

<url>http://repository.javajigi.net:8080/artifactory/repo</url>

<enabled>false</enabled>

</releases>

</pluginRepository>

</pluginRepositories>

</profile>

</profiles>

</settings>

위와 같이 설정한 다음 Maven 빌드툴을 실행해보자. Maven 중앙 Repository에서 다운되는 모든 라이브러리가 Artifactory Repository에 다음과 같이 저장된다.

Artifactory에 라이브러리 배포하기

개 발하고 있는 라이브러리를 사내 Maven Repository에 배포하여 관리할 필요가 있다. 프로젝트간의 Dependency를 관리하기 위하여 개발 라이브러리를 사내 Maven Repository에 배포하고 사용할 수 있도록 개발 환경을 설정하는 것이 중요하다.

Artifactory에 라이브러리를 배포하는 방법은 Artifactory 관리툴을 이용하는 방법과 Maven 빌드툴을 이용하는 방법이 있다.

Artifactory 관리툴을 이용하는 방법은 간단하다. Artifactory 관리툴의 Deploy an artifact를 이용하여 새로운 라이브러리를 배포할 수 있다. 배포할 라이브러리를 업로드하면 다음과 같이 라이브러리에 대한 정보를 입력하는 것이 가능하다.

이 방법은 3rd party 라이브러리를 관리할 때 유용하게 사용할 수 있는 방법이다. 개발하고 있는 라이브러리를 매번 이 방식으로 배포하기에는 적합하지 않다. 개발을 진행하는 중에는 상당히 자주 배포할 필요가 있기 때문에 개발 환경에 바로 배포할 수 있어야 한다. Maven 빌드툴은 deploy goal을 통하여 사내 Repository에 배포하는 것이 가능하도록 지원한다.

로컬에 설치한 Artifactory에 개발 라이브러리를 배포하기 위해서 먼저 USER_HOME/.m2/settings.xml 파일에 다음과 같이 Artifactory 인증에 필요한 정보를 추가해야 한다.

<settings 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/xsd/settings-1.0.0.xsd">

      <servers>

            <server>

                  <id>organisation-internal</id>

                  <username>admin</username>

                  <password>password</password>

            </server>

      </servers>

      <profiles>

      ....

      </profiles>

</settings>

Artifactory에 로그인할 때 사용했던 username과 password를 이용하여 인증이 가능하도록 설정한다.

다음은 개발 프로젝트의 pom.xml 파일에 다음과 같이 배포할 서버를 지정해야 한다.

<distributionManagement>

        <repository>

            <id>organisation-internal</id>

            <name>MyCompany Repository</name>

            <url>

                http://repository.javajigi.net:8080/artifactory/private-internal-repository

            </url>

        </repository>

</distributionManagement>

위와 같이 설정한 후 "mvn deploy"를 실행하면 로컬에 설치한 Artifactory에 개발 라이브러리를 배포하는 것이 가능함.

개발 라이브러리르 배포하면 다음과 같이 private-internal-repository에 배포되게 된다.

이상으로 Artifactory의 설치와 간단한 사용방법에 대하여 살펴보았다. 더 자세한 정보는 Setting Up a Maven Repository문서와 Artifactory 사이트에서 얻을 수 있다.

Maven 을 이용하여 프로젝트를 관리하고 있다면 반드시 사내 Maven Repository가 필요하다. 사내 Maven Repository가 존재하지 않는다면 사내 프로젝트들간의 복잡도를 관리하기가 쉽지 않다. 또한 3ry party 라이브러리나 중안 Maven Repository에서 관리하지 않는 라이브러리를 다른 방식으로 관리해야되기 때문에 라이브러리 관리에 복잡도를 증가시키는 결과를 가져올 수 있다.

Maven 강좌 7 - Maven을 이용하여 Appfuse 프로젝트 생성하기

Appfuse 프로젝트 소개

Appfuse는 다양한 프레임워크의 조합으로 프로젝트를 진행할 때 템플릿을 생성하기 위한 오픈 소스 프로젝트이다. Appfuse를 이용하면 진행하는 프로젝트의 프레임워크 조합에 따라 샘플 프로젝트를 생성할 수 있다. 이 샘플 프로젝트를 기반으로 개발 환경을 구축하는 것이 가능하다.
Appfuse가 지원하는 프레임워크를 살펴보면 다음과 같다.

JSF Basic
Spring MVC Basic
Struts 2 Basic
Tapestry Basic

위 예는 프리젠테이션 레이어를 담당하는 프레임워크들이다. 그외 Hibernate, IBatis등 다양한 프레임워크의 조합의 템플릿 프로젝트를 생성하는 것이 가능하다.

지금까지 진행한 Maven 강좌를 이해하고 있다면 이번 강좌는 쉽게 이해할 수 있을 것이다.

Appfuse 프로젝트 생성

Appfuse는 각 프레임워크의 조합에 따라 각각 다른 archetype을 제공하고 있다. Appfuse에서 제공하는 archetype은 http://appfuse.org/display/APF/AppFuse+QuickStart에서 확인할 수 있다. 이번 강좌의 예제에서는 Spring MVC Basic을 이용하도록 하겠다.

먼저 DOS Prompt에서 Appfuse 프로젝트를 생성하고자하는 디렉토리로 이동한 다음 Spring MVC Basic archetype을 생성한다.

mvn archetype:create -DarchetypeGroupId=org.appfuse.archetypes -DarchetypeArtifactId=appfuse-basic-spring \

-DremoteRepositories=http://static.appfuse.org/releases -DarchetypeVersion=2.0 -DgroupId=net.javajigi.app -DartifactId=myappfuse

위와 같이 실행하면 Appfuse 디렉토리 하위에 myappfuse라는 디렉토리가 생기면서 템플릿 프로젝트가 생성된다. Maven 디폴트 디렉토리 구조로 다음과 같이 생성된다.

Maven archetype을 통하여 생성된 myappfuse 디렉토리 하위를 보면 pom.xml 파일이 생성되어 있는 것을 확인할 수 있다. Appfuse 예제를 테스트하기 위하여 데이터베이스 설정을 해야 한다. pom.xml 파일을 열어 자신의 데이터베이스 설정과 맞도록 수정해준다. 이 문서에서는 Mysql 데이터베이스를 사용하여 예제를 진행했다.

<dbunit.dataTypeFactoryName>

    org.dbunit.dataset.datatype.DefaultDataTypeFactory

</dbunit.dataTypeFactoryName>

<dbunit.operation.type>CLEAN_INSERT</dbunit.operation.type>

<hibernate.dialect>org.hibernate.dialect.MySQLInnoDBDialect</hibernate.dialect>

<jdbc.groupId>mysql</jdbc.groupId>

<jdbc.artifactId>mysql-connector-java</jdbc.artifactId>

<jdbc.version>5.0.5</jdbc.version>

<jdbc.driverClassName>com.mysql.jdbc.Driver</jdbc.driverClassName>

<jdbc.url>

    <![CDATA[jdbc:mysql://localhost/myappfuse?createDatabaseIfNotExist=true&amp;useUnicode=true&amp;characterEncoding=utf-8]]>

</jdbc.url>

<jdbc.username>root</jdbc.username>

<jdbc.password>password</jdbc.password>

위 와 같이 데이터베이스 설정을 변경한 다음 myappfuse 디렉토리로 이동한 다음 mvn install eclipse:eclipse 명령을 실행하여 Eclipse 프로젝트를 생성한다. Eclipse 프로젝트를 생성한 다음 Eclipse에서 import한다. mvn install eclipse:eclipse 명령을 실행하면 관련 라이브러리를 다운받는데 많은 시간이 소요된다.

mvn install eclipse:eclipse를 실행하면 Maven 기반의 프로젝트를 Eclipse 프로젝트로 변환할 뿐만 아니라 빌드까지 진행하게 된다. 생성한 myappfuse 프로젝트는 WTP 기반의 프로젝트로 생성된다.

Maven의 Eclipse 플러그인 활용에 대한 자세한 내용은 Maven 강좌 5 - Maven 기반의 Eclipse 프로젝트 생성 및 활용에서 확인할 수 있다.

Appfuse 프로젝트 테스트

생성한 myappfuse 프로젝트를 Eclipse에서 import한다.

appfuse를 WTP와 연동하기 위해서는 추가적인 설정이 필요하다. 기본적으로 Maven 기반의 프로젝트를 Eclipse로 변경할 경우 특별한 추가 설정이 필요없다. 그러나 appfuse는 Common 프로젝트와 이 프로젝트와 의존관계에 있는 프로젝트로 분리되어 있기 때문에 추가적인 설정이 필요하다.

생성한 myappfuse 프로젝트의 pom.xml 파일을 열어보면 다음과 같이 war 파일과 의존관계를 가지는 것을 알 수 있다.

<dependency>

            <groupId>org.appfuse</groupId>

            <artifactId>appfuse-${web.framework}</artifactId>

            <version>${appfuse.version}</version>

            <type>war</type>

</dependency>

Maven의 경우 war 파일과 의존관계에 있을 경우 빌드시 war 파일을 다운받아 빌드 디렉토리에 압축을 풀어 같이 배포할 수 있도록 지원한다. appfuse 프로젝트를 생성하면 webapp 디렉토리는 다음 그림과 같다.

그러나 Maven을 이용하여 빌드를 하면 target 디렉토리가 다음과 같이 구성되는 것을 확인할 수 있다.

디폴트 Eclipse 플러그인은 src/main/webapp를 디폴트 웹 리소스 디렉토리로 인식한다. 그러나 빌드 후 Common war 파일이 target 디렉토리에 배포되기 때문에 WTP 설정 파일을 다음과 같이 변경해야 된다.

.settings 디렉토리 아래의 org.eclipse.wst.common.component 파일을 연다.

<wb-resource deploy-path="/" source-path="src/main/webapp"/> 삭제
<wb-resource deploy-path="/" source-path="target/myappfuse-1.0-SNAPSHOT"/> 추가
<wb-resource deploy-path="/WEB-INF/classes" source-path="src/main/resources"/> 삭제

다음 단계는 myappfuse 프로젝트를 Tomcat 서버에 배포하여 테스트를 진행하는 과정에 대하여 살펴보도록 하겠다.

Preferences -> Java -> Installed JREs로 이동하여 JDK를 추가한다. 디폴트는 JRE가 설정되어 있을 것이다. JRE가 아니라 JDK를 추가한다.

JDK를 설정한 다음 Tomcat 서버를 추가해야 한다.
Preferences -> Server -> Installed Runtimes: Apache -> Tomcat 5.5 server를 선택하여 로컬에 설치한 Tomcat 5.5를 추가한다. Tomcat 5.5를 추가할 때 앞에서 추가한 JDK 5.0을 사용하도록 한다.

Window -> Show View -> Other -> Server -> Servers로 이동한 다음 새로운 서버를 추가한다.

오른쪽 클릭 New -> Server

위와 같이 myappfuse 프로젝트를 WTP 기반 프로젝트로 설정되어 있기 때문에 서버를 추가할 때 배포하도록 설정하는 것이 가능하다. 추가한 서버를 시작한다.

서버를 시작한 다음 http://localhost:8080/myappfuse로 접근하면 다음과 같은 로그인 화면을 볼 수 있다면 appfuse에 대한 설정이 성공한 것이다.

admin/admin으로 로그인하면 다음 화면과 같이 Appfuse의 기능을 확인할 수 있다.

Appfuse가 가지는 기능은 간단하다. 단순히 사용자들을 관리할 수 있는 기능을 제공하고 있다. 따라서 다양한 오픈 소스 프레임워크 조합으로 애플리케이션을 개발할 때 템플릿 프로젝트로 시작하기에 좋다. Appfuse를 분석하여 개발환경을 세팅하기 위한 샘플 프로젝트로 활용하기에 충분하다. 오픈 소스 프레임워크를 활용하기 힘들어하는 개발자들이 분석하기에 규모면에서 좋은 예제라고 생각한다.

또한 Appfuse가 가지고 있는 Maven에 대한 활용 예제로서 분석하는 것도 좋은 공부가 될 것이다.

Maven 강좌 8 - Maven 플러그인을 이용하여 Apache Tomcat 서버에 소스 배포하기

Tomcat에 소스를 배포하기 위한 Maven 플러그인은 http://mojo.codehaus.org/tomcat-maven-plugin/introduction.html 에서 찾을 수 있다. 설정은 생각보다 간단하다. Maven 설정 파일인 pom.xml 파일에 다음과 같이 설정해 주시만 하면 된다.

<build>

<plugins>

    <plugin>

    <groupId>org.codehaus.mojo</groupId>

    <artifactId>tomcat-maven-plugin</artifactId>

    </plugin>

</plugins>

</build>

위와 같이 설정하면 Apache Tomcat의 manager 기능을 이용하여 소스를 배포하는 것이 가능해진다.

tomcat-maven-plugin을 위와 같이 디폴트로 설정하면 http://localhost:8080/manager를 접근 URL을 사용하며, 디폴트 사용자는 id : admin, password : 없음dmf 디폴트로 사용한다.

Tomcat 서버에 manager에 접근할 수 있는 사용자를 추가하는 방법은 다음과 같다.

CATALINA_HOME/conf/tomcat-users.xml 파일을 다음과 같이 설정하면 된다.

<?xml version='1.0' encoding='utf-8'?>

<tomcat-users>

  <role rolename="manager"/>

  <user username="admin" password="" roles="manager"/>

</tomcat-users>

tomcat-maven-plugin 설정에 관한 자세한 사용 방법은 http://mojo.codehaus.org/tomcat-maven-plugin/configuration.html에서 확인할 수 있다.

pom.xml 파일에 위와 같이 설정한 다음 maven을 빌드할 때 goal을 실행하면 된다.

tomcat:undeploy tomcat:deploy

배포한 소스를 Undeploy한 다음 Deploy하는 방식으로 서비스를 재배포하는 것이 가능하다.

필자가 삽질한 이유는 Undeploy할 때 Tomcat Server가 애플리케이션을 삭제한다.

그런데 Spring 프레임워크의 Load Time Weaving(이하 LTW) 기능을 이용하기 위하여 spring-agent.jar 파일 javaagent로 등록한 이유 때문에 Tomcat에 배포한 프로젝트가 정상적으로 삭제되지 않았기 때문이다.

현재 Spring의 LTW 기능을 제거함으로서 문제를 해결해다.

Spring의 LTW 기능이 좋은 기능이기는 하지만 이래 저래 신경써야 할 부분들이 많다는 것이 단점이다.

저작자표시

DonzBox

DonzBox

태그

최근글

댓글

공지사항

아카이브

관련글

티스토리툴바