Ch3. The Project Object Model
Central Conept of Maven 인 Project Object Model에 대해서 설명.
project의 identity, structure 정보가 모델링되어 있으며, pomx.xml 파일로 정의된다.
Diving into morespecifics, take a look at Figure 3.1 for a survey of the contents of a POM
위 그림에서 POM을 보다시피 프로젝트의 description and configuration은 크게 4 종류가 있다.
3.2.1 The Super POM
참고:superPOM의 파일 위치는 maven 버젼마다 다르다.
SuperPOM의 낯짝을 보자,
근데 궁금한게 Central Repository의 역할이 뭐지?
snapshot repository를 활용한다는 것이 뭐임?
...
ㅁ pom.xml 뜯어보기
- 프로젝트에 대한 종속성, 구성 및 기타 중요한 정보에 대한 정보가 포함 된 XML 파일
다음은 pom.xml 파일에 포함 된 정보 목록입니다.
- 프로젝트 종속성
- 플러그인
- 프로젝트의 목표
- 프로필
- 버전
- 프로젝트 설명
- 배포 목록
- 개발자
- 소스 폴더의 디렉토리
- 빌드 디렉토리
- 테스트 소스의 디렉토리
Super POM이란?
프로젝트의 POM 파일 간에는 상위-하위 관계가 있습니다. 특정 프로젝트를 위해 개발 한 pom 파일은 super pom의 속성을 상속합니다.
Maven에서 pom.xml 파일의 주요 기능
- 이름: 이름에서 알 수 있듯이 프로젝트의 이름을 설명합니다. 이름과 artifactId간에 차이가 있습니다. artifactId는 프로젝트를 고유하게 식별하고 기본 단계로 간주됩니다. 이름은 읽을 수있는 이름 일 뿐이며 Maven에서 프로젝트를 식별하기위한 필수 단계로 간주되지 않습니다.
- URL : 이것은 프로젝트의 URL을 설명합니다. 이름과 마찬가지로 url은 필수 태그가 아닙니다. 대부분 프로젝트에 대한 추가 데이터를 제공합니다.
- 포장 : 이것은 항아리 또는 전쟁의 형태로 패키지 유형을 자세히 설명합니다.
- 종속성 : 프로젝트의 종속성을 설명합니다. 각 종속성은 종속성 태그의 일부입니다. 종속성 태그에는 여러 종속성이 포함됩니다.
- 의존: groupId, artifactId 및 버전과 같은 개별 종속성 정보를 설명합니다.
- 범위: 그들은 프로젝트의 주변을 설명합니다. 가져 오기, 시스템, 테스트, 런타임, 제공 및 컴파일과 같은 다음 값을 가질 수 있습니다.
- 계획: pom.xml 파일의 루트 태그입니다.
- 모델 버전 : 이것은 프로젝트 태그의 일부입니다. 모델 버전을 정의하고 Maven 2 및 3의 경우 값은 4.0.0으로 설정됩니다.
2. Maven이 참조하는 설정 파일
Maven 전체를 보기보다 프로그래밍에 직접적인 연관이 있는 두 개의 설정파일을 알아보면 된다.
1) settings.xml
settings.xml은 maven tool 자체에 관련된 설정을 담당한다.
MAVEN_HOME/conf/ 아래에 있다. ( * MAVEN_HOME은 환경변수에 설정한 경로)
Maven 자체에 설정 값을 바꾸는 일은 일단 잘 없으므로 넘어가고 기획한대로 pom.xml을 살펴본다.
2) pom.xml
- 프로젝트를 관리하기 위한 것.
- 프로젝트에 대한 종속성, 구성 및 기타 중요한 정보에 대한 정보가 포함 된 XML 파일
- 하나의 자바 프로젝트에 빌드 툴로 maven을 설정했다면, 프로젝트 최상위 디렉토리에 "pom.xml"이라는 파일이 생성되었을 것이다.
- pom.xml은 POM(Project Object Model)을 설정하는 부분으로 프로젝트 내 빌드 옵션을 설정하는 부분이다.
<?xml version="1.0" encoding="UTF-8"?>
// 1. 프로젝트 관련 정보
<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/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion> //maven의 pom.xml의 모델 버젼 (4.0.0)
<groupId>com.example</groupId> //프로젝트를 생성한 그룹의 이름
<artifactId>demo</artifactId> // 프로젝트에서 생성되는 기본 아티팩트의 이름
// 메이븐에 의해 생성되는 일반적인 artifact는 <artifact>-<version>.<extention>이다. (ex demo-0.0.1-SNAPSHOT.jar)
<version>0.0.1-SNAPSHOT</version> // : 애플리케이션의 버전. 접미사로 SNAPSHOT이 붙으면 아직 개발단계라는 의미이며, 메이븐에서 라이브러리를 관리하는 방식이 다르다고 한다.
<packaging>jar</packaging> // jar, war, ear, pom등 패키지 유형을 나타낸다.
<name>demo</name> // 프로젝트명
<description>Demo project for Spring Boot</description> //프로젝트 설명
// 위와 같은 태그들은 프로젝트 정보에 관련된 내용이다.
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.0.5.RELEASE</version>
<relativePath/> <!-- lookup parent from repository -->
</parent>
<properties> //pom.xml에서 중복해서 사용되는 설정(상수) 값들을 지정해놓는 부분
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
<java.version>1.8</java.version>
</properties>
// 2. 의존성 라이브러리 정보
// 최소한 groupId, artifactId, version 정보가 필요하다.
// 그리고 A라는 라이브러리를 사용하는데 B,C,D가 의존성을 가진다면 A를 dependency에 추가하면 자동으로 필요한 B,C,D도 가져오는 기능이 있다.
// dependency에 <scope>의 경우 compile, runtime, provided, test등이 올 수 있는데 해당 라이브러리가 언제 필요한지, 언제 제외되는지를 나타내는 것으로 따로 검색해보면 알 수 있다.
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-devtools</artifactId>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
</dependencies>
// 3. build 정보
// build tool : maven의 핵심인 빌드와 관련된 정보를 설정할 수 있는 곳이다
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
</plugins>
</build>
</project>
출처: https://jeong-pro.tistory.com/168 [기본기를 쌓는 정아마추어 코딩블로그]
3. build 정보
<build> 부분에서 설정할 수 있는 값들에 대해 설명하기 전에 "라이프 사이클(life-cycle"에 대해서 알 필요가 있다.
객체의 생명주기처럼 maven의 프로젝트에는 라이프 사이클이 존재한다. (프로젝트 자체를 개체로 바라보기 때문, 관리 측면에서 편하다)
크게 default, clean, site 라이프 사이클로 나누고 세부적으로 페이즈(phase) 있다. 아래 그림 참조
* 라이프 사이클
- mvn process-resources : resources:resources의 실행으로 resource 디렉토리에 있는 내용을 target/classes로 복사한다.
- mvn compile : compiler:compile의 실행으로 src/java 밑의 모든 자바 소스를 컴파일해서 target/classes로 복사
- mvn process-testResources, mvn test-compile : 이것은 위의 두 개가 src/java였다면 test/java의 내용을 target/test-classes로 복사. (참고로 test만 mvn test 명령을 내리면 라이프사이클상 원본 소스로 컴파일된다.)
- mvn test : surefire:test의 실행으로 target/test-classes에 있는 테스트케이스의 단위테스트를 진행한다. 결과를 target/surefire-reports에 생성한다.
- mvn package : target디렉토리 하위에 jar, war, ear등 패키지파일을 생성하고 이름은 <build>의 <finalName>의 값을 사용한다 지정되지 않았을 때는 아까 설명한 "artifactId-version.extention" 이름으로 생성
- mvn install : 로컬 저장소로 배포
- mvn deploy : 원격 저장소로 배포
- mvn clean : 빌드 과정에서 생긴 target 디렉토리 내용 삭제
- mvn site : target/site에 문서 사이트 생성
- mvn site-deploy : 문서 사이트를 서버로 배포
위와 같은 진행 순서로 라이프 사이클이 진행된다.
이제 <build>에서 설정할 수 있는 값을 확인해보자.
<finalName> : 빌드 결과물(ex .jar) 이름 설정
<resources> : 리소스(각종 설정 파일)의 위치를 지정할 수 있다.
- <resource> : 없으면 기본으로 "src/main/resources"
<testResources> : 테스트 리소스의 위치를 지정할 수 있다.
- <testResource> : 없으면 기본으로 "src/test/resources"
: 빌드할 때 접근할 저장소의 위치를 지정할 수 있다. 기본적으로 메이븐 중앙 저장소인 http://repo1.maven.org/maven2로 지정되어 있다.
<outputDirectory> : 컴파일한 결과물 위치 값 지정, 기본 "target/classes"
<testOutputDirectory> : 테스트 소스를 컴파일한 결과물 위치 값 지정, 기본 "target/test-classes"
<plugin> : 어떠한 액션 하나를 담당하는 것으로 가장 중요하지만 들어가는 옵션은 제 각각이다. 다행인 것은 플러그인 형식에 대한 것은 안내가 나와있으니 그것을 참고해서 작성하면 된다.
plugin이 작성되어 있다고 무조건 실행되는 것은 아니다. 명확한 것은 아니지만 따로 실행할 플러그인을 메이븐 명령어로 실행해야 하는 것으로 알고 있다.
- <executions> : 플러그인 goal과 관련된 실행에 대한 설정
- <configuration> : 플러그인에서 필요한 설정 값 지정
출처: https://jeong-pro.tistory.com/168 [기본기를 쌓는 정아마추어 코딩블로그]
출처: https://jeong-pro.tistory.com/168 [기본기를 쌓는 정아마추어 코딩블로그]
3.2.2 The Simplest POM
All Maven POMs inherit defaults from the Super POM
Such a simple POM would be more than adequate for a simple project
- 왜냐하면, 예를들어 e.g., a Java library that producesa JAR file. It isn’t related to any other projects, it has no dependencies, and it lacks basic informatio nsuch as a name and a URL.
- If you were to create this file and then create the subdirectorysrc/main/javawith some source code, runningmvn packagewould produce a JAR intarget/simple-project-1.jar.
3.2.3 The Effective POM
3.3 POM Syntax --> XML을 따른다.
The POM is always in a file named pom.xml in the base directory of a Maven project. This XML documentcan start with the XML declaration, or you can choose to omit it. All values in a POM are captured as XML elements.
3.3.1 Project Versions
- 3.3.1.1 Version Build Numbers
- 3.3.1.2 SNAPSHOT Versions
3.3.2 Property References
The syntax for using a property in Maven is to surround the property name with two curly braces andprecede it with a dollar symbol.
3.4 Project Dependencies
Maven can manage both internal and external dependencies.
- An external dependency for a Java projectmight be a library such as Plexus, the Spring Framework, or Log4J.
- An internal dependency is illustratedby a web application project depending on another project that contains service classes, model objects, orpersistence logic.
1st dependency = compile dependency (X Fire SOAP library from Codehaus)
2nd dependency = test-scoped dependency on JUnit
last dependency = project dependencies (Serverlet 2.4 API)
3.4.1 Five Dependency Scope
3.4.2 Optional Dependencies (이해 X)
다음의 상황을 가정해보자. you are working on a library that provides caching behavior. Instead of writing a cachingsystem from scratch, you want to use some of the existing libraries that provide caching on the filesystem and distributed caches.
To cache on the file system, you’ll want touse a freely available library called EHCache
n other words, you need both libraries to compile this library project, but you don’t want both librariesto show up as transitive runtime dependencies for the project that uses your library. You can accomplishthis by using optional dependencies
Declaring Optional Dependencies
n an ideal world, you wouldn’t have to use optional dependencies. Instead of having one large projectwith a series of optional dependencies
3.4.4 Transitive Dependencies
3.4.5 Conflict Resolution
..
3.5 Project Relationships