Maven 은 간단하게 말하자면 Project Management Framework 라고 할 수 있다...
POM(Project Management Object)이란 녀석을 이용하여 빌드에서부터 시작해서 의존성 관리 및 배포까지 모든 것을 관리할 수 있다..
Maven을 이용하면 Coherence, Reusability, Agility, Maintainability 등을 제공한다고 한다...
아직 잘 모르면서 그냥 쓰고 있기 때문에 저런 장점을 제공하는지는 잘 모르겠다... -_-;;
대체 Maven이 어떤 철학을 가지고 있길래 저런 것들을 제공하는지 한 번 알아보자...
1. Convention Over Configuration
관념이 설정보다 우선한다는 말인데 이게 대체 무슨 말인가...
Ruby on Rails 에서 유명하게 된 말이라고 하는데 간단하게 말하자면 디폴트로 뭔가 정해 놓고 그건 신경쓰지 말고 쓰자는 말이다..
물론 설정을 통해 자신이 원하는대로 변경할 수 있지만 신경 쓸 필요 없는 걸 구지 신경쓰지 말잔 말이다..
Maven 에서는 다음과 같은 3가지를 제공하면서 위의 철학을 실현하고 있다..
- tandard Directory Layout
말 그대로 디렉토리 구조를 미리 정해 놓은 것이다. 소스파일, 설정파일, 빌드파일, 도큐먼트 등의 위치를 정해놓고 그대로 쓰자는 얘기다. - Separation Of Concerns
하나의 프로젝트에서는 하나의 결과물을 가지도록 하는 것이다. 이를 통해 재사용성을 증가시킬 수 있다. 이는 바로 다음에 살펴볼 빌드 로직을 재사용하는 것에서 쉽게 확인할 수 있다. - Standard Naming Conventions
디렉토리와 결과물의 이름 규칙도 정해져 있다. 예를 들어 commons-loggin-1.2.jar 란 파일이 있다고 하면 commons logging의 버전 1.2를 사용한다는 것을 쉽게 알 수 있다. 자바의 get/set 메소드도 하나의 예라고 할 수 있다.
2. Reuse of Build Logic
Maven에서는 빌드 로직을 플러그인이란 이름의 모듈로 만들어 놓았다. 이런 플러그인에는 컴파일, 테스트, 패키징, 문서화 등등 수 많은 플러그인들이 존재한다. 여기서 아주 중요한 사실은 Maven은 이와 같은 플러그인들의 실행 결과가 모여서 최종 결과를 낸다는 것이다. 이런 플러그인들을 Maven의 설정 파일인 POM(Project Object Model)에 설정하게 되면 Build Life Cycle에 따라 실행되고 최종 결과물을 출력하게 된다.
3. Declarative Execution
위에서 잠깐 알아보았듯이 Maven에서는 POM(Project Object Model)에 모든 설정을 하게 된다. 그러면 POM이 무엇이고 잠깐 살펴본 Build Life Cycle이 무엇인지 알아보도록 하자.
POM(Project Object Model)
Maven에서는 하나의 프로젝트에 하나의 POM을 가진다. POM은 XML 형태로 구성되어 있고 아래는 아주 간단한 예제이다.
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany.app</groupId>
<artifactId>my-app</artifactId>
<packaging>jar</packaging>
<version>1.0-SNAPSHOT</version>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
</project>
위의 15줄에 불과한 POM을 사용하면 컴파일, 테스트 및 문서화까지도 가능하다. 어떻게 이런 일이 가능할까... 왜냐하면 Maven은 묵시적으로 Super POM을 사용하기 때문이다. 자바의 Object 클래스와 같은 역할을 한다고 보면 된다. 그렇다면 각각의 속성에 대해 간단하게 알아보도록 하자.
<project> - pom.xml 파일의 ROOT. 무조건 이 속성으로 시작해야 한다.
<modelVersion> - 현재 POM이 사용하고 있는 버전을 나타낸다. 이 버전은 자기 마음대로 정해주면 되는데 적당히 잘 해주도록 하자.
<groupId> - 프로젝트를 만든 조직이나 그룹의 유일한 식별자이다. 보통 자바 패키지 만드는 형식으로 지정해주면 된다. 물론 안 그렇게 해도 된다.
<artifactId> - 프로젝트에서 생성하는 결과물의 이름에 사용되는 속성이다. Maven에서는 <artifactId>-<version>.<extension> 같은 형식의 파일 이름으로 패키징 해준다. 위의 예제는 my-app-1.0-SNAPSHOT.jar 와 같은 형태로 만들어지게 된다.
<packaging> - 패키징 할 파일 형식을 지정한다. (JAR, WAR, EAR 등등) 뿐만 아니라 빌드 프로세스의 부분으로 사용하기 위한 특정 Life Cycle을 나타내기도 한다. 그냥 Build Life Cycle을 커스터마이징 할 때 사용된다고 알아두면 된다고 한다. -_-;;
<version> - 프로젝트의 버전을 표시한다. 위에 SNAPSHOT이라고 붙은 것은 개발 상태일 때 붙인다고 한다.
<name> - 프로젝트의 이름
<url> - 프로젝트 사이트
<description> - 프로젝트 설명
다른 자세한 내용은 http://maven.apache.org/maven-model/maven.html 여기에 가면 확인할 수 있다. 일단 이정도 까지만 살펴보고 나머지는 뒤에 나올 것 같으니 일단 넘어가도록 하자...
Build Life Cycle
그렇다면 계속 말이 나오던 Build Life Cycle에 대해서 알아보자.
일반적으로 소프트웨어 프로젝트는 비, 컴파일, 테스트, 패키징, 인스톨과 같은 비슷한 전형적인 경로를 갖는다.
Maven에서는 이러한 경로를 Build Life Cycle이라고 부른다.
Maven의 Build Life Cycle은 하나 이상의 Action 또는 Goal 들을 수행하는 여러 개의 단계들로 구성되어 있다.
예를 들어 complie 단계는 클래스들을 컴파일하는데 필요한 Goal들의 집합을 실행시키게 된다는 말이다. 또
한 Maven에서 상위 레벨의 단계를 실행시키고자 하면 하위 레벨의 단계를 먼저 실행시켜주게 된다. 또 다시 complie을 예로 든다면 Maven은 이 단계를 실행하기 위해 하위 레벨 단계인 validate, initialize, generate-sources, process-sources, generate-resources 를 실행한 후에 complie을 수행하게 된다.
이처럼 Build Life Cycle은 많은 단계들로 구성되어 있고 또한 이를 확장할 수도 있다.
아까 위에서 빌드 로직을 모듈화해서 플러그인으로 만들어 놓은 것들이 바로 Build Life Cycle의 하나의 단계이다.
4. Coherent Organization of Dependencies
이번에는 Maven에서 의존성 관리를 어떻게 해주는지 살펴보도록 하자. 아까 살펴본 POM 예제를 다시 살펴보도록 하자.
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany.app</groupId>
<artifactId>my-app</artifactId>
<packaging>jar</packaging>
<version>1.0-SNAPSHOT</version>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
</project>
딱 보면 알 수 있듯이 junit 란 녀석에게 의존성을 갖는 것을 알 수 있다.
의존성이란 Repository 에 존재하는 특정 라이브러리 파일에 대한 참조를 말한다.
Maven에서는 이런 의존성을 해결하기 위해 어떤 라이브러리 파일을 어떤 Repository를 살펴봐야 하는지 정보가 필요하다.
이런 것들은 groupId, artifactId, version 속성을 사용해서 식별하게 된다.
라이브러리가 물리적으로 어디에 존재하는지 또한 파일을 다운로드 받을 필요도 없다.
그저 위에서 처럼 설정만 하면 junit (groupId) 에서 제공하는 junit (artifactId) 의 3.8.1 (version) 에 의존성이 있다고 명시만 하면 된다..
그렇게 하면 Maven에서 이용 가능한 모든 Remote Repository를 뒤져서 사용자의 Local Repository로 복사해준다.
Maven에는 방금 살펴본대로 2가지 Repository가 존재한다.
Remove Repository는 말 그대로 해당 라이브러리를 다운로드 받을 수 있는 곳을 말한다.
Local Repository는 Maven을 처음 설치하고 실행하게 되면 모든 의존성이 있는 라이브러리를 모아 놓는 곳이다.
기본적으로 사용자의 홈 디렉토리에 ~/.m2/repository 요런 식으로 생성되게 된다.
위의 의존성을 해결하게 되면 사용자 홈 디렉토리에 다음과 같은 형식으로 해당 라이브러리 파일이 저장되게 된다.
repository
└ groupId
└ artifactId
└ version
├ artifactId-version.jar
├ artifactId-version.jar.sha1
├ artifactId-version.pom
└ artifactId-version.pom.sha1
만약 groupId가 org.apache.maven 이라면 자바의 패키지 생성과 같은 방식으로 org - apache- maven 디렉토리가 생성되고 그 아래에 나머지 구조대로 생성되게 된다.
Maven은 이처럼 의존성을 해결할 때 먼저 Local Repository에 /repository/groupId/artifactId/version/artifactId-version.jar 파일이 존재하는지 확인한다.
만약 존재하지 않는다면 Remote Repository에서 다운로드 받아 Local Repository의 해당 위치에 복사하게 된다.
Maven은 Remote Repository로 http://www.ibiblio.org/maven2 를 기본으로 사용한다.
또한 Maven은 여러 개의 Remote Repository를 가질 수 있는데 POM에 정의된 순서대로 찾아가게 된다.
이렇게 Local Repository를 사용하면 여러 개의 프로젝트에서 같은 파일을 사용해도 하나의 파일만 존재하면 된다.
또한 버전별로 관리할 수 있으므로 쓸데 없는 라이브러리를 프로젝트에 추가하지 않을 수 있게 된다.
휴.. 이렇게 대충 Maven이 어떤 것이고 어떤 구조를 가지고 있으며 무슨 생각으로 이렇게 만들었는지 살펴보았다...
다음번에는 실제로 Maven을 사용해보도록 하자!!
아래 사이트에 가보면 Maven 다운로드 받을 수 있고 간단하게 설치하는 방법도 설명되어 있다.
http://maven.apache.org/download.html
그냥 압축 풀고 환경변수만 세팅해주면 끝난다.
제대로 설치했다면 커맨드 창에 mvn -version이란 명령이 실행되어야 한다.
윈도우즈 환경에서 실행했다면 아래와 비슷한 메세지가 출력되는 것을 볼 수 있다.
Maven version: 2.0.10
Java version: 1.6.0_06
OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
설치가 끝났다.. 이제 한 번 Maven 프로젝트를 생성해보자..
Maven에서는 초간단하게 프로젝트를 만들 수 있는 템플릿을 제공하는데 아래와 같이 archetype 이란 명령을 사용하면 된다.
mvn archetype:create -DgroupId=com.test.app -DartifactId=test-app
위의 명령을 실행하면 뭔가 막 다운로드 받으면서 마지막에 BUILD SUCCESSFUL 이란 글자를 확인할 수 있다.
처음 실행 시에 다운로드 받는 것들은 Remote Repository 에서 Local Repository 로 필요한 라이브러리를 복사하는 과정이다.
다음에 다시 실행하면 이미 받은 라이브러리들은 다운로드 받지 않게 된다.
아무튼 생성된 프로젝트를 살펴보면 아래와 같은 구조로 만들어져 있는 것을 볼 수 있다.
test-app
├ src
│ ├ main
│ │ └ java
│ │ └ com
│ │ └ test
│ │ └ app
│ │ └ App.java
│ └ test
│ └ java
│ └ com
│ └ test
│ └ app
│ └ AppTest.java
└ pom.xml
일단 artifactId 가 루트 디렉토리로 생성되고 그 안에 아래와 같은 pom.xml 파일이 존재한다.
<modelVersion>4.0.0</modelVersion>
<groupId>com.test.app</groupId>
<artifactId>test-app</artifactId>
<packaging>jar</packaging>
<version>1.0-SNAPSHOT</version>
<name>Maven 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에서 제공하는 기본 pom.xml 과 똑같은 형태이다.
아무튼 위에서 볼 수 있는 디렉토리 구조가 바로 Maven에서 사용하는 Standard Directory Layout 이다.
src 폴더에는 main 과 test 디렉토리가 있는데 각각의 디렉토리에 groupId 로 패키지가 만들어지고
해당 디렉토리에는 소스파일, 설정파일 등등이 위치하게 된다.
그리고 App.java 파일을 하나 생성해주는데 Hello World 프로그램이 하나 들어있다.
그렇다면 이제 컴파일을 하기 위해서 pom.xml 파일이 있는 test-app 디렉토리로 경로를 옮겨간다.
이 디렉토리가 test-app 프로젝트에서 ${basedir} 가 되고 이를 이용하여 pom.xml 에서 상수처럼 사용할 수 있다.
자세한 예는 나중에 나올 것 같으니 일단은 알아두고 넘어가자.
단순하게 아래 명령을 실행하면 컴파일이 된다.
mvn compile
정말 간단하다... -_-;;
제대로 했다면 아까 처럼 뭔가 다운로드 받다가 성공했다는 메세지를 볼 수 있을 것이다.
그런데 정말 잘 컴파일이 되었는지 궁금하다.
test-app 디렉토리를 잘 살펴보면 target/classes 디렉토리가 생성되어 있고 그 안에 컴파일된 파일이 있는 것을 볼 수 있다!
그런데 뭔가 좀 이상한 점이 있다...
어떻게 컴파일 하고 컴파일 한 결과를 저 디렉토리에다가 복사해놓았을까...
분명 pom.xml 에는 컴파일에 관련된 아무런 정보도 없는데...
이것이 바로 Convention Over Configuration 이다.
Maven 에서 아무런 설정을 하지 않는다면 소스 디렉토리는 src/main/java 디렉토리가 되고 타겟 디렉토리는 target/classes 가 된다.
위에서 생성된 pom.xml 에서 이런 설정들을 전혀 볼 수 없지만 비밀은 Super POM 이 가지고 있다.
모든 Maven 프로젝트는 Super POM을 상속하고 있고 따로 경로 설정을 하지 않는다면 위의 기본 설정을 사용하게 되는 것이다.
위의 컴파일이 끝나면 소스 코드는 컴파일이 되지만 테스트 코드는 컴파일이 되지 않는다.
Maven은 Build Life Cycle 을 갖는데 compile 이란 Build Logic 은 소스 코드를 컴파일 하는 역할까지만 하도록 되어 있는 것이다.
이렇게 만든 이유는 재사용이 용이하도록 하기 위해서라고 이전에 살펴본 바 있다.
그렇다면 이제 테스트 코드를 컴파일 하고 유닛 테스트를 실행해보도록 하자.
mvn test
끝이다... -_-;;
그냥 위와 같이 해주면 뭔가 다운로드가 끝나면 바로 테스트 코드 컴파일 하고 유닛 테스트까지 실행해준다.
실행 결과를 잘 살펴보면 test 를 실행시키면 compile 과 test-compile 이 먼저 실행되는 것을 볼 수 있을 것이다.
Build Life Cycle이 이렇게 실행되도록 구성되어 있기 때문이다.
만약 테스트 컴파일까지만 하고 테스트를 실행하지 않고자 한다면 mvn test-compile 로 실행하면 된다.
일단 테스트를 실행하면 아래와 같이 Surefile 플러그인이 담당하는 것을 확인할 수 있을 것이다.
T E S T S
-------------------------------------------------------
[surefire] Running com.test.app.AppTest
[surefire] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.001 sec
Results :
[surefire] Tests run: 1, Failures: 0, Errors: 0
여기서 한가지 알고 넘어가야 할 사실은 여기에도 Convention Over Configuration이 적용된다는 것이다.
Surefire 플러그인은 기본적으로 다음과 같은 파일을 찾아서 테스트 코드를 실행시킨다.
**/*Test.java
**/Test*.java
**/*TestCase.java
그리고 기본적으로 다음과 같은 파일은 제외한다.
**/Abstract*Test.java
**/Abstract*TestCase.java
그냥 저런 네이밍 룰을 지키기만 하면 모든걸 편하게 할 수 있다.
이번에는 패키징과 인스톨을 알아보도록 하자.
mvn package
위와 같이 실행시켜주면 pom.xml 에 설정되어 있는 패키지로 (<packaging>jar</packaging> 라면 jar로) 만들어 준다.
mvn install
그리고 나서 위의 명령을 실행하면 Local Repository로 만들어진 jar 파일을 복사해주게 된다.
정말 초간단하게 프로젝트 하나 생성해서 컴파일, 테스트, 패키징, 인스톨까지 완료할 수 있다.
필요한 POM 설정 파일은 위에서 살펴본 pom.xml 파일이 전부이다.
Maven에서는 또 하나의 유용한 플러그인을 제공한다
위에 보는 화면은 방금 우리가 만든 프로젝트의 종합적인 정보를 보여주는 웹페이지다.
저걸 내가 작접 만든게 아니고 mvn site 명령을 실행하면 자동으로 만들어 준다.
지금까지 빌드된 내용을 삭제하고자 한다면 mvn clean 명령을 실행하면 된다.
그리고 사실 요즘에 누가 커맨드 창에서 일일이 입력하고 있을까 싶다..
Maven에서는 IntelliJ IDEA와 이클립스에서 사용할 수 있는 형태로 만들어주는 플러그인도 제공한다.
mvn eclipse:eclipse
위와 같이 실행하면 이클립스 프로젝트로 사용할 수 있도록 .project 파일과 .classpath 파일이 생성된다.
이클립스를 실행한 후에 프로젝트로 등록해서 사용하면 된다.
여기까지 간단하게 프로젝트를 생성하고 Maven을 사용하는 방법을 알아보았다.
일단 Maven에서는 리소스 파일이 src/main/resources 디렉토리에 있으면 해당 파일들을 리소스 파일로 간주한다.
만약 해당 디렉토리에 아래와 같이 test.properties 란 파일이 있다면...
test-app
├ src
│ ├ main
│ │ ├ java
│ │ │└ com
│ │ │ └ test
│ │ │ └ app
│ │ │ └ App.java
│ │ └ resources
│ │ └ test.properties
│ └ test
│ └ java
│ └ com
│ └ test
│ └ app
│ └ AppTest.java
└ pom.xml
mvn complie 명령을 실행해주면 target/classes 폴더에 해당 파일이 복사되는 것을 확인할 수 있다.
만약 mvn install 명령을 실행했다면 생성된 jar 파일에는 다음과 같이 META-INF 폴더가 생성된다.
test-app-1.0-SNAPSHOT.jar
└ META-INF
├ maven
│ └ com.test.app
│ └ test-app
│ ├ pom.properties
│ └ pom.xml
└ MANIFEST.MF
위의 정보는 자동으로 생성된다.
만약 MANIFEST.MF 파일을 직접 만들고 싶다면 maven-jar-plugin 을 사용하면 된다..
아래와 같이 해주면<manifestFile> 태그에 명시된 파일로 변경된다.
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<archive>
<manifestFile>META-INF/MANIFEST.MF</manifestFile>
</archive>
</configuration>
</plugin>
</plugins>
</build>
테스트 클래스패스 리소스도 src/test/resources 디렉토리에 만들어주면 된다.
일반 클래스패스 리소스와 다른 점은 하나도 없다.
자.. 이번에는 리소스 필터링에 대해서 알아보도록 하자.
Maven 에서는 리소스 파일을 동적으로 변경할 수 있는 기능을 가지고 있다.
즉 POM.xml에서 사용하고 있는 모든 속성들을 ${속성이름} 으로 리소스 파일에서 가져다 사용할 수 있다.
만약 아래와 같이 POM.xml 파일에서 filtering을 true로 설정했다면...
<modelVersion>4.0.0</modelVersion>
<groupId>com.test.app</groupId>
<artifactId>test-app</artifactId>
<packaging>jar</packaging>
<version>1.0-SNAPSHOT</version>
<name>test</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>
<build>
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
</resource>
</resources>
</build>
</project>
src/main/resource 디렉토리에 있는 test.properties 파일에...
project.name = ${project.name} 라고 저장하고 mvn process-resources 를 실행하면...
test.properties 파일의 내용은 project.name = test 로 변경된다.
다른 프로퍼티 파일에 있는 내용을 사용할 수도 있는데...
<filters>
<filter>src/main/filters/filter.properties</filter>
</filters>
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
</resource>
</resources>
</build>
위와 같이 설정하게 되면 filter.properties에 있는 속성도 ${속성이름} 형식으로 사용할 수 있게 된다.
POM.xml에서 직접 속성을 설정할 수도 있다.
<test>
<value>hello</value>
</test>
<greeting.hello>hi</greeting.hello>
</properties>
위와 같이 설정하게 되면 ${test.value} 또는 ${greeting.hello} 속성을 사용할 수 있게 된다.
마지막으로 시스템 프로퍼티도 사용할 수가 있다.
예를 들어 java.version 이라던지 기타 등등 System 클래스에서 제공하는 프로퍼티들을 그대로 사용 가능하다.
심지어 -D 옵션으로 넘어오는 커맨드 라인 프로퍼티도 사용가능하다!!
만약 리소스 중에 위와 같은 필터링을 제외하고 싶은 리소스가 있는 경우에는 아래와 같이 설정해주면 된다.
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
<excludes>
<exclude>test/**</exclude>
</excludes>
</resource>
<resource>
<directory>src/main/resources</directory>
<includes>
<include>test/**</include>
</includes>
</resource>
</resources>
</build>
즉 필터링 시에 제외할 리소스를 <exclude> 설정을 통해 제외시키고 제외된 리소스만 따로 <include> 해주면 된다.
다소 복잡해 보일지도 모르겠지만 가만 살펴보만 아주 명시적인 방법이다.
이전에도 살펴보았지만 Maven에서는 빌드를 커스터마이징 할 수 있다.
새로운 플러그인을 추가해서 할 수도 있고 이미 추가되어 있는 플러그인에 파라미터를 설정해서 할 수도 있다.
예를 들어 자바 컴파일러로 JDK 5.0을 사용하고자 한다면 아래와 같이 설정하면 된다.
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.0</version>
<configuration>
<source>1.5</source>
<target>1.5</target>
</configuration>
</plugin>
</plugins>
</build>
<plugin> 태그를 사용하면 되는데 <depedency>와 매우 사용방법이 유사하다.
한가지 다른 점이 있다면 <plugin>은 groupId와 version은 명시하지 않아도 된다는 것이다.
만약 groupId가 없다면 org.apache.maven.plugins 또는 org.codehaus.mojo에서 해당 groupId를 찾게 된다.
그리고 version이 없다면 가장 최신 버전으로 가져오게 된다.
플러그인에 대해 자세한 정보를 얻고자 한다면 아래 주소를 참고하도록 하자.
http://maven.apache.org/plugins
이로써 기본적인 사용 방법은 다 알아보았다.
과연 언제쯤 끝까지 다 볼 수 있을까... -_-;;
- Maven 템플릿 생성
웹 어플리케이션 기반으로 Maven 기본 archetype 중에서 maven-archetype-webapp을 사용하여 user 프로젝트를 생성한다.
명령 프롬프트에서 D:\Project로 이동한 후 다음 명령어를 실행하여 uSopoong_SK 프로젝트를 위한 템플릿을 생성한다.mvn archetype:generate -DgroupId=com.csquare -DartifactId=uSopoong_SK -DarchetypeArtifactId=maven-archetype-webapp위 명령어를 실행하면 D:\Project 디렉토리에 uSopoong 프로젝트가 생성된다. - Maven 빌드
명령 프롬프트에서 D:\Project\uSopoong_SK 디텍토리로 이동한 후 아래 명령을 실행한다.mvn eclipse:eclipse - Eclipse 프로젝트로 가져오기
이클립스 워크스페이스에서 File → Import → General → Existing Projects into Workspace 메뉴를 실행하여 uSopoong_SK프로젝트를 가져오기 한다. - 디렉토리 생성
maven-archetype-webapp은 웹 자원만 관리할 수 있게 Archetype이 생성되어 있다. uSopoong_SK 프로젝트에 src/main/java, src/test/java 디렉토리를 생성한다. - Ecplise WTP 로 구축하기
pom.xml을 다음과 같이 설정하여 eclipse:eclipse Goal을 실행했을 때 WTP 기반 프로젝트가 생성되게 한다.<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"pom.xml 파일에 위 설정을 추가한 후 명령 프롬프트에서
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.csquare</groupId>
<artifactId>uSopoong_SK</artifactId>
<packaging>war</packaging>
<version>1.0-SNAPSHOT</version>
<name>uSopoong_SK Maven Webapp</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>
<properties>
<webapp.context>/</webapp.context>
<maven.compiler.source>1.5</maven.compiler.source>
<maven.compiler.target>1.5</maven.compiler.target>
<maven.compiler.encoding>utf-8</maven.compiler.encoding>
</properties>
<build>
<finalName>uSopoong_SK</finalName>
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>${maven.compiler.source}</source>
<target>${maven.compiler.target}</target>
<encoding>${maven.compiler.encoding}</encoding>
</configuration>
</plugin>
<plugin>
<artifactId>maven-eclipse-plugin</artifactId>
<version>2.4</version>
<configuration>
<wtpContextName>${webapp.context}</wtpContextName>
<downloadSources>true</downloadSources>
<downloadJavadocs>true</downloadJavadocs>
<wtpversion>1.5</wtpversion>
</configuration>
</plugin>
</plugins>
</build>
</project>mvn eclipse:clean eclipse:eclipse를 실행하여 프로젝트 메타데이터를 다시 생성한다.
이클립스 워크스페이스에서 F5 키를 눌러 새로 고침을 하면 개발을 진행할 수 있다.
처음 Ant로 빌드를 시작할 때는 빌드를 자동화하는 것 자체만으로도 매력적이었다. 그러나 시간이 지나면서 프로젝트를 생성할 때마다 매번 만들어야하는 Ant 설정 파일에 슬슬 짜증이 나기 시작했다. 프로젝트가 복잡해지면서 Ant를 사용하는 데 한계를 느끼던 차에 Maven 빌드 툴을 접하게 되었다. Maven에 대해 깊이 알면 알수록 그 매력에 빠지지 않을 수 없었다.
다른 기능을 배제하더라도 외부 라이브러리를 관리하는 의존성 관리(Dependency Management) 기능은 Maven을 사용할 만한 충분한 이유가 되었다. 물론 현재는 이외에도 Maven의 다른 기능을 사용하면서 Maven의 이점을 피부로 느끼고 있다.
아직까지 Maven의 생소한 개발자들이 많을 것이다. 이 책에서는 Maven 기본과 Maven 활용으로 나누어 2개의 장에 걸쳐서 다룬다.
자바지기의 Maven 강의
Maven 강좌 1 - Maven 설치 및 최초 프로젝트 생성
Maven 강좌 2 - Maven 개요, 잇점, POM 설정 파일 기본
Maven 강좌 3 - Maven 디폴트 디렉토리 구조 및 사용할 수 있는 Goals
Maven 강좌 4 - Maven을 이용하여 Dependency 라이브러리 관리 방법
Maven 강좌 5 - Maven 기반의 Eclipse 프로젝트 생성 및 활용
Maven 강좌 6 - Artifactory를 이용하여 Maven Repository 세팅하기
Maven 강좌 7 - Maven을 이용하여 Appfuse 프로젝트 생성하기
Maven 강좌 8 - Maven 플러그인을 이용하여 Apache Tomcat 서버에 소스 배포하기
- Maven 등장배경
Maven은 지금까지 소프트웨어를 개발할 때 반복했던 작업을 자동화하는 빌드 툴이다.
대표적인 빌드툴은 Ant는 빌드, 릴리즈, 배보, 리포팅 등을 진행되어 왔지만 일관된 기준이 없어 프로젝트를 진행할 때마다 대부분 작업을 반복했다. Maven은 프로젝트 관리에 필요한 모든 작업을 추상화하고 표준화해서 반복을 제거했다. - Maven과 Ant의 차이점
Maven은 아래 항목들을 지원하는 저장소가 있다. - 템플릿 프로젝트인 Archetype
- 의존 관계에 있는 라이브러리
- Maven 플러그인
- Maven의 기능
- 빌드(Build)
- 문서화(Documentation)
- 리포팅(Reporting)
- 의존 관계(Dependencies)
- 소스 코드 관리(SCMs)
- 릴리즈(Releases)
- 배포(Distribution)
- Maven의 장점
- 의존 관계인 라이브러리의 관리가 편한다.
- 모든 프로젝트에 일관된 디렉토리 구조와 빌드 프로세스를 유지할 수 있다.
- Maven의 다양한 플러그인(IDE 프로젝트로 자동변환, 데이터베이스 통합, 다양한 리포트 생성 등)을 활용할 수 있다.
- 전사적으로 사용할 프로젝트 템플릿을 만들어 배포할 수 있다.
- Maven 설치
- 다운로드 http://maven.apache.org/download.html 후 설치한다.
- 시스템 환경 변수에 MAVEN_HOME 추가한다.
- 시스템 환경 변수 PATH에 MAVEN_HOME/bin 추가한다.
- 버전확인 mvn -version
2. Maven 기반의 템플릿 프로젝트 생성
- Maven은 생성하는 프로젝트의 종류에 따라 기반이 되는 템플릿 프로젝트를 제공한다. Maven에서 지원하는 Archtype의 기능에는 소스 디렉토리, 테스트 소스 디렉토리, 웹 리소스 디렉토리 등의 기본 설정이 예약되어 있어 정해진 규칙에 따라 프로젝트의 뼈대를 자동으로 생성할 수 있다.
- jar 프로젝트 생성하는 방법mvn archetype:generate -DgroupId=com.hangyeol -DartifactId=myproject -DarchtypeArtifactId=maven-archetype-quickstart디렉토리 구조
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.0http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.hangyeol</groupId>
<artifactId>myproject</artifactId>
<packaging>jar</packaging>
<version>1.0-SNAPSHOT</version>
<name>myproject</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> - war 프로젝트 생성하는방법mvn archetype:generate -DgroupId=com.hangyeol -DartifactId=myproject -DarchtypeArtifactId=maven-archetype-webapp디렉토리 구조
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.0http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.hangyeol</groupId>
<artifactId>mywebproject</artifactId>
<packaging>war</packaging>
<version>1.0-SNAPSHOT</version>
<name>mywebproject Maven Webapp</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>
<build>
<finalName>mywebproject</finalName>
</build>
</project>
3. Maven 설정파일
POM(Project Obect Model)은 프로젝트 정보와 프로젝트를 빌드하는 설정 정보가 있는 XML파일이다.
- project
pom.xml 파일의 최상위 엘리먼트이다. - modelVersion
POM 모델의 버전으로 가장 최근의 버전은 4.0.0이다. - groupId
프로젝트를 생성하는 조직의 고유 아이디를 결정한다. 일반적으로 도메인 이름을 사용한다. - artifactId
프로젝트를 식별하는 유익한 아이디를 의미한다. 예를 들어 com.hangyeol라는 groupId가 있는 조직에는 여러 개의 프로젝트가 존재할 수 있다. - packaging
프로젝트를 어떤 형태(jar, war, ear 등)로 패키징할지 결정한다. - version
프로젝트의 현재 버전이다. 개발이 완료된 버전의 경우 1.0, 2.0과 같이 사용하고, 개발 중인 프로젝트에서는 일반적으로 SNAPSHOT을 접미사로 사용한다.
※ SNAPSHOT
Maven 예약어로써, 개발 중인 프로젝트인 경우에는 라이브러리의 변경시 마다 새로 다운로드 하도록 지원한다. - name
프로젝트의 이름이다. - url
프로젝트 사이트가 있다면 사이트 URL을 등록한다. - dependencies
프로젝트와 의존 관계에 있는 라이브러리를 관리한다.
4. Maven의 디렉토리 구조와 라이프 사이클
- Maven의 라이프 사이클
- compile
소스 코드를 컴파일한다. - test
JUnit, TestNG와 같은 단위 테스트 프레임워크로 단위 테스트를 한다. - package
단위 테스트가 성공하면 압축한다.(jar, war ...) - install
로컬 저장소에 압축한 파 일을 배포한다. - deploy
원격 저장소에 압축한 파일을 배포한다. - clean
빌드 결과물이 위치하는 target 디렉토리를 삭제한다. - site
프로젝트에 관한 웹 사이트를 생성한다. - 소스 컴파일
자원을 복사한 다음에 src/main/java 디렉토리의 자바 소스 코드를 target/classes 디렉토리로 컴파일한다.mvn compile※ 자원 관리하는 방법 - src/main/resources 디렉토리에 있는 모든 자원
- pom.xml 파일에서 재정의
- 테스트 소스 코드 컴파일mvn test-compile
- 테스트
컴파일한 테스트 클래스(target/test-classes)로 구현 클래스를 테스트 한 후 테스트 결과를 target/surefire-reports 디렉토리에 생성한다.mvn test - 패키징
compile, test-compile, test 순으로 실행된 다음 target 디렉토리 아래에 pom.xml에 정의한 형태로 artifactId-version.packaging 또는 finalName.packaging
압축파일을 생성한다.mvn package - 배포하기
Maven 로컬 저장소에 압축한 jar, war 파일을 배포하는 한다.mvn install다른 개발자와 jar, war 파일을 공유하기 위해 로컬에 파일을 원격 저장소에 등록한다.mvn deploy - 빌드 결과물 제거
target 결과물을 모두 제거한다.
target 결과물을 모두 제거한 후 test를 실행한다.
target 결과물을 모두 제거한 후 install을 실행한다.mvn clean
mvn clean test
mvn clean install
5. Maven으로 의존 관계 라이브러리 관계
- Ant에서 Maven으로 전환했을 때 가장 유용하게 사용하는 기능이 의존 관계에 있는 라이브러리를 관리하는 의존성 관리(Dependency Management)이다. Maven은 중앙 저장소엣 관리하는 수많은 라이브러리를 pom.xml 설정만으로 로컬 PC에 자동으로 다운로드하게 된다. 이는 라이브러리를 버전이 변경되더라도 pom.xml 설정 파일의 숮ㅇ만으로 변경된 라이브러리를 반영할 수 있다.
- AS-IS 의존 관계 라이브러리의 관리 방법
- Maven의 의존 관계 관리 기능
- 로컬 저장소 변경
- 의존 관계 랑이브러리의 적용 범위
6. 이클립스 플러그인 활용한 WTP 프로젝트 생성
7. Profile 기능 활용하기
개발 환경에 따라 달라지는 설정 정보를 관리하는 기능을 제공한다.
데이터베이스 설정 정보
로그인 설정 정보
프레임워크와 관련된 설정 정보
서버에 대한 설정 정보
출처 - http://icetiger.tistory.com/entry/Maven%EC%9D%B4%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%BC%EA%B9%8C
'IDE & Build > Maven' 카테고리의 다른 글
| maven - missing artifact (0) | 2014.08.18 |
|---|---|
| maven - 기초 사용법 3 (0) | 2013.06.08 |
| maven - scope (0) | 2013.04.05 |
| maven install such as to add Microsoft SQL JDBC driver to Maven (0) | 2012.12.07 |
| maven 기초 사용법 (0) | 2012.11.21 |
