Portfolio

Maven pom.xml 파일 구조 Goal 정리 goal 종류 Version Scope Gradle implements api, compile(deprecated)compileOnly runtimeOnly 🔖 봐야될 사이트

Maven

메이븐 완전 정복: https://wikidocs.net/book/1910

Maven 명령어 모음


//== Maven 명령어 ==//

// 빌드를 하기전 빌드 결과 위치를 비우는 명령어, 콘솔 명령창에서 수행
mvn clean

// compile 수행 명령어
// compile 후 target 디렉토리가 생성되며 컴파일된 결과물이 만들어짐
// target/classes/HelloWorld.class 파일 확인 가능
mvn compile

// ?? 이건 뭐여??
// 아래의 명령어로 실행하면 Maven Hello World! 가 정상적으로 찍힌다.
// -cp : 클래스 패스 경로
java -cp tartget/classes HelloWorld

// java 패키징 명령어
// target/HelloWorld-1.0-SNAPSHOT.jar 파일이 생성된다.
mvn package

java -jar target/HelloWorld-1.0-SNAPSHOT.jar HelloWorld

pom.xml 파일 구조

프로젝트 정보

modelVersion
groupId
artifactId
version
packaging

properties

maven 내부에서 반복적으로 사용될 상수 값을 정의할 때 사용

Dependencies(의존성 라이브러리 정보)

project 태그 바로 하위
의존성 라이브러리 정보를 포함함
최소 groupId, artifactId, version 정보가 필요함
dependencies 색션 아래 새부 ‘dependency’가 기술됨

빌드(<build>) 정보

project 태그 바로 하위
plugins: 빌드에서 사용할 플러그인
디렉토리 구조

Repository

의존성을 다운로드 받을 위치의 repository
기술되지 않을 시 기본적인 위치

http://repo.maven.apache.org/maven2

다수의 <repository> 기술 가능
회사 내부의 repository를 기술 하기도 한다.

nexus
artifactory를 이용

Plugin Repository

maven plugin을 다운로드 받을 수 있는 저장소 위치를 기술

배포

deploy goal을 실행했을 시, 배포되는 위치를 기술함
url 항목에는 일반적으로 회사 내부에 설치한 repository url이 기술된다.(nexus, artifactory 등으로 설치된..)


<distributionManagement>
    <repository>
        <id>releases-repo</id>
        <name>Releases Repository</name>
        <url>일반적인 회사 내부 repository url</url>
    </repository>
    <snapshotRepository>
        <id>snapshots-repo</id>
        <name>Snapshots Repository</name>
        <url>일반적인 회사 내부 repository url</url>
    </snapshotRepository>
</distributionManagement>

Goal 정리

Goal

Maven이 행할수 있는 여러가지 동작을 수행하는 명령을 Goal이라고 함.
실행방식, 체인 형태로 실행 가능


mvn [goal명령어] [goal명령어] [goal명령어]

goal 종류

clean : 컴파일 결과물인 target 디렉토리 삭제

compile : 모든 소스 컴파일, 리소스 파일을 target/classes 디렉토리에 복사

package : compile 수행 후, 테스트 수행, <packaging> 정보에 따라 패키징 수행

install : package

deploy : install 수행 후, 배포 수행, 여기서 배포는 웹서버에 배포가 아니다. 회사 repo에 배포다.

아래와 같이 distributionManagement 항목이 기술되어야 한다.


...생략
    <distributionManagement>
        <repository>
            <id>releases-repo</id>
            <name>Releases Repository</name>
            <url>회사repository주소(넥서스)</url>
        </repository>
        <snapshotRepository>
            <id>snapshots-repo</id>
            <name>Snapshots Repository</name>
            <url>회사repository주소(넥서스)</url>
        </snapshotRepository>
    </distributionManagement>

Version

SNAPSHOT

ex) 1.0-SNAPSHOT
개발진행 중임을 나타낸다.
version이 변경되지 않았더라도 항상 변경사항을 다운로드 한다.
소문자로는 작동하지 않는다.

특별 네이밍이 없는 경우

ex) 1.0.1
특별 네이밍이 없는 경우는 release 상태를 의미

일반적인 관용어구는 maven에 특별한 기능을 부여하지 않는다. 즉 SNAPSHOT에만 특별한 동작을 한다.

ex) 1.0-RC1 (release candidate)
ex) 1.0-M1 (milestone release)
ex) 1.0-RELEASE (release)

Scope

dependency 하위에 포함되는 항목

해당 dependency가 포함되는 범위에 대한 타입

scope 종류

compile :

기본 scope. 미입력시에도 기본 적용

모든 상황에서 포함됨

provided :

compile과 유사하게 모든 상황에서 수행된다

하지만, 다른 외부 컨테이너에서 기본 제공되는 API인경우 provided로 지정 시 마지막 패키징할 때 포함되지 않음

예를 들면 tomcat에서 기본적으로 servlet api를 제공하기 때문에 servlet api를 provided로 지정하면 패키징시 제외된다.

runtime :

컴파일 시에는 불필요 실행시에 필요한 경우.

런타임 및 테스트 시 classpath에 추가 되지만, 컴파일시에는 추가 되지 않음

test : 테스트시에만 사용

system :

provided와 유사

system의 특정 path를 참조하도록 지정

Maven의 central repository를 사용하지 않음

import :

scope는 dependencyManagement 섹션에서 pom의 의존관계에 대해 사용

Gradle

java-library 플러그인이 gradle에 적용될 때 사용 가능한 구성. 출처: Gradle Java Library Plugin

implements

의존 라이브러리 수정 시 해당 모듈을 의존하고 있는 모듈들 또한 재빌드

A ← B ← C 일 때, A에서 C 접근 불가능

B 수정 시, A까지 재빌드

api, compile(deprecated)

의존 라이브러리 수정 시 해당 모듈을 의존하고 있는 모듈들 또한 재빌드 모듈에서 api나 compile을 사용해서 라이브러리를 가져오면, 의존하는 모듈에도 가져와 진다.

A(api) ← B(api) ← C B만 노출되어야 되는데, C의 인터페이스까지 같이 노출

C 수정 시, A와 B 모두 재빌드

api 종속성이 많이 있으면 빌드 시간이 상당히 증가

종속성의 API를 별도의 모듈에 노출시키고 싶은 것이 아니라면 implementation 추천

Leak 발생 → B를 빌드하면서 이미 들어간 C가 중복으로 A에도 추가되기 때문

compileOnly

컴파일 시에만 필요하고, 런타임 시에는 불필요한 경우

컴파일할 때는 해당 종속성을 사용하고 build 에서는 제외

build 크기를 줄일 수 있다는 장점

compileClassPath에만 사용되고 소비자에게 노출되지 않는다.

(compileClassPath : 컴파일 시에만 필요한 class path)

예시로 Lombok : 컴파일 때 만들어지고 런타임 때는 사용되지 않음

runtimeOnly

컴파일 시에는 불필요 하고, 런타임 시에만 필요한 경우

컴파일 시간이 빨라지는 장점

runtimeClassPath에만 사용되고 소비자에게도 노출 된다.

runtimeClassPath : 런타임 시에 필요한 class path

예시로 h2, mysql, log4j

🔖 봐야될 사이트

Gradle Configurations Explained: What is the difference between API and Implementation?

Gradle dependencies are grouped into sets called configurations. Different configurations are used for building classpath for the major two tasks - compile classpath is used for compilation and runtime classpath is used for running the application.

https://medium.com/agorapulse-stories/gradle-configurations-explained-4b9608dd5e35

Maven & Gradle