Maven

빌드와 배포를 위한 툴 Maven.

빌드란 무엇인가

빌드란 소스개발에서 최종 사용자에게 전달될때까지의 전 과정,
즉 프로젝트의 생명주기 전체를 아우르는 행위를 말하
는데, 프로젝트의 규모가 클수록 정형화된 개발환경, 다양한 라이브러리 의존성 관리, 코드 품질 관리 및 결함 관리등의
필요성이 제기되며 빌드 관리 툴을 이용하여 이러한 요구를 해결할 수 있다. 전체 빌드 과정은 그 주체에 따라 개발자 개인의 PC 에서 빌드를 하여 작동 가능한 코드를 생성하는 개인 빌드와 개발 서버에서 프로젝트 개발자들의 작성 코드를
통합하여 빌드를 수행하는 통합 빌드로 구성되는데, 본 교재에서는 전자정부프레임워크 스펙에 기반하여 개인 빌드에
Maven을 통합 빌드에 오픈 소스 CI 서버인 Hudson 을 사용하도록 한다.

의존성 관리? 많은 라이브러리들을 하나하나 찾아서 다운받는다? NO

Maven 설치

[1] 환경변수 설정

jar을 받을때 직접 다운로드 받지 않고
한곳에 일괄적으로 관리하는 방법 -> 중앙저장소

아래 페이지가 중앙저장소로 쓰이는 웹이다.

이 파생된 jar중 내가 쓸 jar은 어떻게 찾아올까?
아파치의 커먼스 io를 가져오고 싶을때

위 org.apache.commons가 아파치의 커먼스 io를 식별해서 가져오게 된다.

이렇게 중앙저장소에서 찾고자하는 jar를 식별해 찾는것이 1단계이다.

2번째로 필요한것은 이 가져온 jar을 저장할 로컬 저장소가 필요하다.

open file을 눌러보면 xml파일이 화면에 표시된다.

위에 지정한 경로가 로컬저장소가 된다.

위 폴더가 있다면 maven을 사용할 준비는 다 된것이다.

앞으로는 이 두개가 가장 많이 쓰일 저장소이다.

중앙저장소에는 우클릭 이후에 인덱싱작업을 해줘야 리스트가 나온다.

Maven 사용 실습

체크해준다

우리가 만든 프로젝트를 Maven에 넣어야하는데
Group id는 베이스
Artifact id는 제품이름

스탠드얼론 페이지일땐 jar
웹어플리케이션일때는 war

war은 WAS에게 가져다주면 자동으로 언패킹해준다. 때문에 대부부 war패키징으로 사용하지만 우리는 스탠드 얼론으로 할 것임.

최종적으론

이렇게 세팅해주자.

Maven이 제공해주는 템플릿 프로젝트를 만들고 각 페이즈를 지원할 수 있는 플러그인을 받아온다.
이제 이 만들어진 프로젝트는 로컬저장소에 저장된다.

이렇듯 자동으로 언패킹해주고 생성해준다.

이렇게 자동으로 만들어지는 구조가 템플릿이다.

여기서 주 개발영역은

이 두녀석이 된다.

이중 자바코드는 java. src와 같다고 보면 된다.
resources는 res라고 보면 된다.

이 처음보는 두녀석은 프로그램이 안정적으로 실행이 되는지 테스팅 코드를 실행할 수 있도록 지원해주는 녀석들이다.

나중에 운영서버로 배포할땐 이 테스트코드들은 제외시켜야한다.
이 기능을 Maven은 자동으로 해주어 배포시 이 폴더는 자동으로 제외해준다.

사실 프로젝트가 만들어질때는 이런식으로 생성된다.
이 폴더들은 우리가 건들지는 않는다.
만일 이 폴더에서 실행시 프로그램은 인지하지 못한다.

자세히보면 여기서 빠져있는게 있다.

이런 클래스 패스가 빠져있다.

이 역할을 이 폴더가 해준다.

이렇듯 보면 클래스 패스가 구분되어 있는걸 볼 수 있다.
왜 테스트 폴더가 제외되는지 알 수 있다.

이는 스탠드얼론 방식으로 만들고 있으므로 main스레드가 필요하다.

컴파일 이후 target에 구조가 만들어지게 된다. 따라서 클래스 패스임을 알 수 있다.

리소스에 폴더를 만들어보자

실제로보면 기존의 우리가 했던 방식과 같은 것을 볼 수 있다.

test

컴파일은 잘 된다.

하지만 따른 클래스 패스에 저장되기 때문에 배포시 제외된다.

제너릭 생략은 1.7이후 가능한데 이상하게 컴파일되지 않는다. 때문에 컴파일에 대한 설정이 필요하다.

Maven에선 모든것을 POM으로 관리한다.
하나의 프로젝트를 관리할때 이를 객체형태로 로딩하는데 각 행동이라는 단계를 페이즈라고 하는데 아래 5개가 페이즈이다.

소스라는 산출물이 나오면 이를 판별하고 파일이 만들어지고 마지막으로 패키징한다.
그런데 각 과정마다 지원하는 플러그인이 다른데

이 그림에서 이를 구별시킨다.

어렵다 더 쉬운 그림으로 보자

난 1.5가 싫으니까 1.7로 줘! 할때 POM.xml에 설정한다.

중앙저장소에서 봤던 정보들이 보이는 것을 볼 수 있다.

왼쪽메뉴 클릭

maven을 통해 컴파일을 할 수 있는 문장이다.
이를 포함한 플러그인의 재설정이 필요하다.

재설정이 실행된다.

이렇듯 3.8.1 버전의 컴파일러가 적용된 것을 볼 수 있다.
이런 xml코드를 빌드 스크립트라고한다.

하지만 아직도 버전은 바뀌지 않는다 이를 위해 설정이 더 필요하다.

소스는 jar버전을 세팅할 수 있다.

실제 빌드시에도 1.8로 실행되도록 설정해준다.

이제 Maven에서 이 xml을 언제 읽어줄까?
만일 수시로 읽는다?
IO가 걸려 부하가 걸린다.
프로젝트 업데이트로 해준다.

버전이 바뀐걸 볼 수 있고

에러가 사라진걸 볼 수 있다.

다시보자 컴파일은 완료했다.
이제 배포를 위한 압축이 필요한데, 이를 위해 패키징을 한다. 그리고 최종적으로는 서버에 이를 배포한다
라이프사이클 페이즈들을 Maven만으로도 지원이 가능하다.

메이븐의 두번째 기능, 의존성

사실 플러그인이든 뭐든 중앙저장소에 있다.

네트워크 상황에 따라 검색이 늦을 수 있음.

그럴땐 직접 중앙저장소에서 검색한다.

오른쪽의 xml코드를 카피하자.

org.apache.commons 에서 버전 선택
이미 중앙저장소에 접속한 이력이 있어 검색이 빠르다.

아니면 이전에 카피한 코드를 붙여넣어도 된다.

위와 같이 가져온것을 볼 수 있음

우리가 이전에 작업한 소스, 자바독을 인스톨레이션에 설정했던 부분이 필요없다.

마샬링 또한 잭슨이라는 라이브러리가 필요했는데,

UI로도 추가가 가능하다.

우리가 필요한건 jar인데 bundle이 있다.

선택

타입을 지워주고 저장해주면 jar이 들어간다.

만일 아무리해도 검색이 잘 안된다면

이사이트에 접속해 검색한다.

스크립트 카피하고 save

이렇듯 의존성관리가 가능하다.

빌드 방법

clean으로 목절을 설정해주면

빌드 끝.
압축(패키징)이 필요하다

자동으로 플러그인을 받아오는데

컴파일이 되는 것을 볼 수 있다.
이는 공정 단계에서 필요한 단계이기때문이다.

일단 테스트에 에러가 없는지 확인후 공정이 진행된다.

최종적으로 이렇게 만들어지며 이를 잘 팔도록 하자 😆

여기까지가 스탠드얼론으로 메이븐을 사용하는 방법이다.
어휴 힘들어..

이제 웹애플리케이션용 메이븐 사용법

선택하는 템플릿이 전과정에선 생략되었다.

체크해서

기존 다이나믹웹고 비슷하나 이상한점은 WebContent가 없다는 것이다.

바로 이곳이 WebContent와 같은 역할을 한다.
html css js image들을 이쪽에 넣는다.

그런데 에러가 나있다?
이는 Web.xml이 없기 때문이다.

xml이 없다면 true로 설정하라고 설명해준다.

웹 구조를 만들어주는 플러그인이 이 플러그인인데, 이 플러그인을 넣어줘야한다.

또한 버전도 바꾸어주어야한다.

이런식으로 프로퍼티를 이용할 수도 있다.
그럼 버전만 설정해주면 된다.

이 버전은 중앙저장소에 저장된 버전이 아니다.

확인해보면 다른 버전도 들어가 있다.

org.apache.maven.plugins
maven-war-plugin
3.3.1ㄹㄹ
카피

업데이트 해주면 에러는 사라진다.

web.xml을 사용안하려면 이녀석이 3점대여야함

프로젝트 알트 엔터 후


적용해도 바뀌진 않는다.

다시 한번 읽을 수도 없는데 이를 강제로 읽을 수 있도록

xml이만들어짐

ctrl 쉬프트 F

이를 지워보면 신기하게도 3.1로 바뀐다

이후 다시 한번더 하면

3.1로 바뀐걸 볼 수 있음

그런데 아파치 톰캣이 옶넹?
톰캣을 다시 넣어야 할까?
아니 pom.xml에서 넣자

조만간 우리나라는 4점대로 바꿀듯하다.

왼쪽에서 넣어야 할걸 오른쪽에 넣고 있었다..

이렇게 만들어지는데 개발할땐 얘를 사용한다.

앞으로 이 컴파일 스코프를 가장 이용할 것.

이중 provided는배포시에는 버리겠다는 것임.

얘는 테스트용이며 배포가 되지 않음

이 둘에서만 사용가능

얘낸불가 이게 스코프를 쓰는 이유이다.

다시 프로바이드로 바꾸자.

우리는 이버전을 사용했다.

이 두 녀석의 차이점은 다르다 프로바이드가 없는건 컴파일이므로 배포시에도 같이 끌고갈거라는 것.

잠깐 프로젝트 삭제

클린한번 해주자

컨텍스트 패스가 저렇게 잡힌다..

lib 없네?

근데 있네?

얘는 비어있다?

pom.xml에서 설정한 jar이 들어가 있는데
나머지 두개를 프로바이드로 적용되어서 배포가 안된걸 볼 수 있음.
하지만 없어도 이를 담고있음.

클래시스파일이 만들어졌다.

타겟인데 war로 되어있음

우리는 이 war파일만 배포서버에 가져다 놓으면 완료된다..

아 정말 어렵다.. 최대한 많이 갖고 놀자