Maven Build Lifecycle
maven을 사용함에 있어서 사용될 수 있는 명령어들이 있는데 이 명령어와 관련된 것이 build lifecycle이다.
1) LifeCycle
- 미리 정해진 빌드순서
- 메이븐은 프레임워크이기 때문에 동작 방식이 정해져있고, 미리 정의하고 있는 빌드 순서가 있다. 이를 라이프사이클(Lifecycle)이라 한다.
- mvn 이라는 명령어로는 compile, test, package 등을 실행할 수 있으며 이러한 compile, test, package 등 Phases(단계)라고 부른다.
수행 단계 종류
◎ Default(Build) : 일반적인 빌드 프로세스를 위한 모델이다.
◎ Clean : 빌드 시 생성되었던 파일들을 삭제하는 단계
◎ Validate : 프로젝트가 올바른지 확인하고 필요한 모든 정보를 사용할 수 있는지 확인하는 단계
◎ Compile : 프로젝트의 소스코드를 컴파일 하는 단계
◎ Test : 유닛(단위) 테스트를 수행 하는 단계(테스트 실패시 빌드 실패로 처리, 스킵 가능)
◎ Pacakge : 실제 컴파일된 소스 코드와 리소스들을 jar, war 등등의 파일 등의 배포를 위한 패키지로 만드는 단계
◎ Verify : 통합 테스트 결과에 대한 검사를 실행하여 품질 기준을 충족하는지 확인하는 단계
◎ Install : 패키지를 로컬 저장소에 설치하는 단계
◎ Site : 프로젝트 문서와 사이트 작성, 생성하는 단계
◎ Deploy : 만들어진 package를 원격 저장소에 release 하는 단계
최종 빌드 순서는 compile => test => package 이다.
① compile : src/main/java 디렉토리 아래의 모든 소스 코드가 컴파일 된다.
② test : src/test/java, src/test/resources 테스트 자원 복사 및 테스트 소스 코드 컴파일 된다.
※ junit : 단위 테스트 프레임워크. 테스트 단계를 거치기 위해 의존 설정을 해준다.
③ packaging : 컴파일과 테스트가 완료 된 후, jar, war 같은 형태로 압축하는 작업.
위 그림은 maven을 통해 만든 프로젝트의 build up 단계이다. 그렇다면 이러한 단계를 일일이 다 실행해야 할까?
만약 compile 명령을 수행 한다면 validate부터 compile까지 앞 단계를 자동으로 진행되며 package 수행 시 validate부터 package까지 진행된다. 각 단계들을 필요에 의해 배제될 수 있다.
packaging 수행 시 원하는 확장자를 결정할 수 있으며 설정한 확장자에 따른 단계를 조금씩 다를 수도 있다. 하지만 일반적으로 단계를 비슷하다.
확장자는 POM.xml에서 편집이 가능하다.
POM은 Project Object Model이라고 하며 프로젝트를 구성하고 있는 내용들을 하나의 Model 로 갖고 있는 파일이다.
그렇다면 이 lifecycle 단계를 위와 같이 정적으로 정해져있는 것일까? NO!!
Maven 은 각 phase에 따라 plug-in 방식으로 즉, 개별 단계별로 실행이 가능하다. 만약에 compile을 실행한다면 compile을 해주는 프로그램이 따로 존재하고 각각 단계를 진행하는 개별 프로그램들이 존재한다.
우리가 자바 프로젝트를 Maven으로 만들었다면 위와 같이 기본적으로 설정되는 것들이 있다. 그리고 해당 단계에 해당하는 프로그램들이 맵핑되어 있다. 즉, 이러한 해당 단계를 실행할 때 사용하는 프로그램을 Plug-in이라고 한다.
위 그림을 보면 Not defined으로 정의된 단계들을 Plug-in이 연결되지 않은 상태를 나타낸다.
즉, 단계들을 존재하지만 Plug-in이 연결된 단계만 실행이 된다는 것이다.
또한 Not defined으로된 단계에 Plug-in을 연결하는 설정, 이미 연결된 Plug-in 설정 변경, Plug-in 버전 변경과 같은 모든 작업은 POM.xml에서 한다.
해당 Plug-in 내에 내부적으로 분리되어있는 작은 단위의 프로그램을 goal이라 칭한다.
정리하자면 Phase(단계)가 있고 우리가 해당 명령어를 실행할 것이며 이 단계를 실행하는 프로그램은 Plug-in이라고 해서 POM.xml에서 설정을 해야하고 설정을 하지 않으면 기본 설정을 기반으로 진행된다.
2) Phase(단계)
Build Lifecycle의 각각의 단계를 Phase라고 한다.
Phase는 의존관계를 가지고 있어 해당 Phase가 수행되려면 이전 단계의 Phase가 모두 수행되어야 한다.
즉, 모든 빌드단계는 이전 단계가 성공적으로 실행되었을 때 실행된다는 것이 Dependency 입니다.
3) Goal
- 특정 작업, 최소한의 실행 단위(task).
- 하나의 플러그인에서는 여러 작업을 수행할 수 있도록 지원하며, 플러그인에서 실행할 수 있는 각각의 기능(명령)을 Goal이라고 한다.
(각각의 Phase에 연계된 Goal을 실행하는 과정을 Build라고 한다.)
- 플러그인의 goal을 실행하는 방법은 다음과 같다.
■ - mvn groupId:artifactId:version:goal(아래와 같이 생략 가능)
■ - mvn plugin:goal
해당 내용은 터미널(커맨드)에서 다음과 같은 명령을 통해 확인할 수 있다.
mvn help:describe -Dcmd=compile
#4 Maven 설정파일
1) settings.xml
- 메이븐 빌드 툴과 관련한 설정파일
- MAVEN_HOME/conf 디렉토리에 위치 (메이븐 설치 시 기본 제공)
- settings.xml의 설정
** 메이븐을 빌드할 때 의존 관계에 있는 라이브러리, 플러그인을 중앙 저장소에서 개발자 PC로 다운로드 하는위치(로컬저장소)의 기본 설정 'USER_HOME/.m2/repository' 인데 settings.xml의 에 원하는 로컬 저장소의 경로를 지정, 변경할 수 있다.
2) POM(프로젝트 객체 모델(Project Object Model))
- POM은 pom.xml파일을 말하며 pom.xml은 메이븐을 이용하는 프로젝트의 root에 존재하는 xml 파일이다.
(하나의 자바 프로젝트에 빌드 툴을 maven으로 설정하면, 프로젝트 최상위 디렉토리에 "pom.xml"이라는 파일이 생성된다.)
- Maven의 기능을 이용하기 위해서 POM이 사용된다.
- 파일은 프로젝트마다 1개이며, pom.xml만 보면 프로젝트의 모든 설정, 의존성 등을 알 수 있다.
- 다른 파일이름으로 지정할 수도 있다. (mvn -f 파일명.xml test). 하지만 pom.xml으로 사용하기를 권장한다.
ex) POM.XML 예시 (기본 SpringBoot 프로젝트의 Pom.xml 파일)
<?xml version="1.0" encoding="UTF-8"?>
<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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion> <!--POM model의 버전-->
<parent> <!--프로젝트의 계층 정보-->
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.2.4.RELEASE</version>
<relativePath/> <!-- lookup parent from repository -->
</parent>
<groupId>com.god</groupId> <!--프로젝트를 생성하는 조직의 고유 아이디를 결정한다. 일반적으로 도메인 이름을 거꾸로 적는다.-->
<artifactId>bo</artifactId> <!--프로젝트 빌드시 파일 대표이름 이다. groupId 내에서 유일해야 한다.Maven을 이용하여 빌드시 다음과 같은 규칙으로 파일이 생성 된다.
artifactid-version.packaging. 위 예의 경우 빌드할 경우 bo-0.0.1-SNAPSHOT.war 파일이 생성된다.-->
<version>0.0.1-SNAPSHOT</version> <!--프로젝트의 현재 버전, 프로젝트 개발 중일 때는 SNAPSHOT을 접미사로 사용-->
<packaging>war</packaging> <!--패키징 유형(jar, war, ear 등)-->
<name>bo</name> <!--프로젝트, 프로젝트 이름-->
<description>Demo project for Spring Boot</description> <!--프로젝트에 대한 간략한 설명-->
<url>http://goddaehee.tistory.com</url> <!--프로젝트에 대한 참고 Reference 사이트-->
<properties>
<!-- 버전관리시 용이 하다. ex) 하당 자바 버전을 선언 하고 dependencies에서 다음과 같이 활용 가능 하다.
<version>${java.version}</version> -->
<java.version>1.8</java.version>
</properties>
<dependencies> <!--dependencies태그 안에는 프로젝트와 의존 관계에 있는 라이브러리들을 관리 한다.-->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-tomcat</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
<exclusions>
<exclusion>
<groupId>org.junit.vintage</groupId>
<artifactId>junit-vintage-engine</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
<build> <!--빌드에 사용할 플러그인 목록-->
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
</plugins>
</build>
</project>
▶ 엘리먼트
◎ modelVersion : POM model의 버전
◎ parent : 프로젝트의 계층 정보
◎ groupId : 프로젝트를 생성하는 조직의 고유 아이디를 결정한다. 일반적으로 도메인 이름을 거꾸로 적는다.
◎ artifactId : 프로젝트 빌드시 파일 대표이름 이다. groupId 내에서 유일해야 한다. Maven을 이용하여 빌드시 다음과 같은 규칙으로 파일이 생성 된다.
artifactid-version.packaging. 위 예의 경우 빌드할 경우 bo-0.0.1-SNAPSHOT.war 파일이 생성된다. (하단 예시 파일 참고)
◎ version : 프로젝트의 현재 버전, 프로젝트 개발 중일 때는 SNAPSHOT을 접미사로 사용.
◎ packaging : 패키징 유형(jar, war, ear 등)
◎ name : 프로젝트, 프로젝트 이름
◎ description : 프로젝트에 대한 간략한 설명
◎ url : 프로젝트에 대한 참고 Reference 사이트
◎ properties : 버전관리시 용이 하다. ex) 하당 자바 버전을 선언 하고 dependencies에서 다음과 같이 활용 가능 하다.
<version>${java.version}</version>
◎ dependencies : dependencies태그 안에는 프로젝트와 의존 관계에 있는 라이브러리들을 관리 한다.
◎ build : 빌드에 사용할 플러그인 목록