오늘 다루어볼 포스팅 내용은 Maven Multi Module을 이용한 Spring Boot Project 만들기입니다. 우선 Maven Multi Module 프로젝트란 하나의 부모 Maven Project를 생성하고 그 밑으로 자식 Maven Module들을 가지는 구조입니다. 부모의 pom.xml에 공통적인 의존 라이브러리를 넣어주면 다른 자식 Maven Module에서는 그대로 사용이 가능합니다. 또한 JPA관련된 모든 소스코드를 common이라는 Maven Module로 만들어서 다른 Maven Module에서 사용하여 공통적인 중복코드를 줄일 수도 있습니다. 바로 예제로 들어가겠습니다.

Maven Multi Project

모든 예제는 Eclipse + Mac OS 기반으로 작성되었습니다.

오늘 구성해볼 프로젝트 구조입니다. 나중에 OAuth2.0 포스팅에서 다루어 봤던 예제를 다시 정리하여 올릴 소스를 정리할겸 구조를 잡아보려고합니다. 간단히 프로젝트 구조에 대해 설명하자면 oauth2라는 Maven Project를 생성할 겁니다. 이것이 바로 부모 Maven Project가 됩니다. 그리고 그 하위 자식 Maven Module로 authorizationserver,resourceserver,client 세개의 모듈을 만들겁니다. 그리고 마지막으로 공통적으로 사용할 JPA관련 프로젝트를 common이라는 공통 Maven Module로 만들어 모든 자식 모듈에서 import하여 사용하도록 할 것입니다. common이라는 공통 JPA 프로젝트를 만드는 이유는 만약 3개의 자식 Maven Module들이 같은 DB를 공유하고 있다면 중복되는 코드를 대폭 줄일 수 있습니다. 바로 예제로 들어가겠습니다.

첫번째로 Package Explorer에서 오른쪽 클릭하여 New를 선택합니다. 그리고 Maven Project를 클릭합니다.

Create a simple project를 클릭하고 Next 버튼을 누릅니다.

Group Id와 Artifact Id를 입력해주고 Packaging을 pom으로 바꾸어준후 Finish를 클릭합니다. 잘 생성이 되었다면 oauth2프로젝트가 생성이 되고 그 밑으로는 src 폴더와 pom.xml이 생성되어 있을 겁니다. src폴더는 삭제해줍니다.

oauth2 프로젝트에 위의 pom.xml 코드를 삽입해줍니다. 그러면 이후에 생성되는 Maven Module들은 위의 라이브러리 설정들을 상속받게 됩니다.oauth2라는 부모 프로젝트를 오른쪽 클릭하여 New를 클릭하고 Maven Module을 클릭해줍니다.

Next 를 클릭합니다.

생성할 Module 이름을 작성한 후에 Next를 누릅니다.

현재 select 되어있는 Artifact Id를 누른 후에 Next 버튼을 누릅니다.

적당한 Group Id를 정해줄 수 있지만 저는 부모 Maven Project 꺼를 default로 사용하였습니다.

나머지 모든 Module도 동일하게 생성해줍니다. 아마 위와 같은 구조로 생성이 되어있을 겁니다. 하지만 우리가 생각하는 Spring Boot 프로젝트와는 거의 유사하지만 없는 것들이 존재합니다. src/main/resources 입니다. 프로젝트를 오른쪽클릭하여 Project Bulid Path를 누르고 source tab에서 add Folder를 해줍니다. 그리고 main을 클릭하고 새로운 resources 폴더를 생성합니다. 그리고 resources의 bulid 경로를 바꿔줍니다.

src/main/resources output folder를 edit해줍니다.

target/classes를 경로로 잡습니다. 그러면 이제 이 프로젝트는 bulid 이후 해당 경로로 리소스들을 떨궈줄것입니다.

Excluded를 **로 설정할겁니다. 그래야 해당 디렉토리로 폴더를 생성하면 패키지처럼 보이지 않을겁니다.

마지막으로 Spring Boot Main 클래스처럼 @SpringApplication 어노테이션을 달고 main method에 run method를 달아줍니다.

여기까지 Maven Multi Module Spring boot Project 만들기였습니다.

1. 메이븐이란?

주로 java 진영에서 프로젝트 빌드, 관리에 사용되는 도구이다. 개발자들이 전체 개발과정을 한 눈에 알아볼 수 있다. 아파치 프로젝트이다.

maven의 특징

• 빌드 절차 간소화

• 동일한 빌드 시스템 제공

• 프로젝트 정보 제공

ant와의 차이점

• Ant가 비교적 자유도가 높다. 전처리, 컴파일, 패키징, 테스팅, 배포 가능

• Maven은 정해진 라이프사이클에 의하여 작업 수행하며, 전반적인 프로젝트 관리 기능까지 포함하고 있음. (Build Tool + Project Management)

gradle과의 차이점

• XML 대신 groovy 스크립트를 사용하여 동적인 빌드 가능.

• maven은 멀티프로젝트에서 상속구조인데, gradle은 주입 방식이다. 멀티프로젝트에서 gradle이 더 적합하다.

2. 플러그인

• 메이븐은 플러그인을 구동해주는 프레임워크(plugin execution framework)이다. 모든 작업은 플러그인에서 수행한다.

• 플러그인은 다른 산출물(artifacts)와 같이 저장소에서 관리된다.

• 메이븐은 여러 플러그인으로 구성되어 있으며, 각각의 플러그인은 하나 이상의 goal(명령, 작업)을 포함하고있다. Goal은 Maven의 실행단위이다.

• 플러그인과 골의 조합으로 실행한다. ex. mvn <plugin>:<goal> = mvn archetype:generate

• 메이븐은 여러 goal을 묶어서 lifecycle phases 로 만들고 실행한다. ex. mvn <phase> = mvn install

플러그인 목록

3. 라이프사이클

메이븐은 프로젝트 생성에 필요한 단계(phases)들을 Build Lifecycle이라 정의하고 default, clean, site 세가지로 표준 정의한다. Lifecycle은 Build Phase 들로 구성되며 일련의 순서를 갖는다. phase 는 실행단위로서 goal과 바인딩된다.

아래 사진은 Build default 라이프사이클의 주요 phase이고 그 밑에는 전체이다.

• clean : 빌드 시 생성되었던 산출물을 삭제

1. pre-clean : clean 작업 전에 사전작업
2. clean : 이전 빌드에서 생성된 모든 파일 삭제
3. post-clean : 사후작업

• default : 프로젝트 배포절차, 패키지 타입별로 다르게 정의됌

1. validate : 프로젝트 상태 점검, 빌드에 필요한 정보 존재유무 체크
2. initialize : 빌드 상태를 초기화, 속성 설정, 작업 디렉터리 생성
3. generate-sources : 컴파일에 필요한 소스 생성
4. process-sources : 소스코드를 처리
5. generate-resources : 패키지에 포함될 자원 생성
6. compile : 프로젝트의 소스코드를 컴파일
7. process-classes : 컴파일 후 후처리
8. generate-test-source : 테스트를 위한 소스 코드를 생성
9. process-test-source : 테스트 소스코드를 처리
10. generate-test-resources : 테스팅을 위한 자원 생성
11. process-test-resources : 테스트 대상 디렉터리에 자원을 복사하고 가공
12. test-compile : 테스트 코드를 컴파일
13. process-test-classes : 컴파일 후 후처리
14. test : 단위 테스트 프레임워크를 이용해 테스트 수행
15. prepare-package : 패키지 생성 전 사전작업
16. package : 개발자가 선택한 war, jar 등의 패키징 수행
17. pre-integration-test : 통합테스팅 전 사전작업
18. integration-test : 통합테스트
19. post-integration : 통합테스팅 후 사후작업
20. verify : 패키지가 품질 기준에 적합한지 검사
21. install : 패키지를 로컬 저장소에 설치
22. deploy : 패키지를 원격 저장소에 배포

• site : 프로젝트 문서화 절차

1. pre-site : 사전작업
2. site : 사이트문서 생성
3. post-site : 사후작업 및 배포 전 사전작업
4. site-deploy : 생성된 문서를 웹 서버에 배포

4. 의존성

개발자는 프로젝트에 사용할 라이브러리를 pom.xml에 dependency로 정의만 해두면 메이븐이 repository에서 검색해서 자동으로 추가해준다. 심지어 참조하고있는 library까지 모두 찾아서 추가해준다. 이것을 '의존성 전이' 라고 한다.

의존관계 제한 기능

불필요한 라이브러리 다운로드를 방지하기 위해 추가기능을 제공한다.

• Dependency mediation : 버전이 다른 두 개의 라이브러리가 동시에 의존 관계에 있을 경우 Maven은 좀더 가까운 의존관계에 있는 하나의 버전만을 선택

• Dependency management : 직접 참조하지는 않으면서 하위 모듈이 특정 모듈을 참조할 경우, 특정 모듈의 버전을 지정

• Dependency scope : 현재 Build 단계에 꼭 필요한 모듈만 참조할 수 있도록 참조 범위를 지정

compile : 기본값, 모든 classpath에 추가, 컴파일 및 배포 때 같이 제공

provided : 실행 시 외부에서 제공, 예를들면 WAS에서 제공되어 지므로 컴파일 시에는 필요하지만, 배포시에는 빠지는 라이브러리들

runtime : 컴파일 시 참조되지 않고 실행때 참조

test : 테스트 때만

system : 저장소에서 관리하지 않고 직접 관리하는 jar 파일을 지정

import : 다른 pom파일 설정을 가져옴, <dependencyManagemet>에서만 사용

• Excluded dependencies : 임의의 모듈에서 참조하는 특정 하위 모듈을 명시적으로 제외처리

• Optional dependencies : 임의의 모듈에서 Optional로 참조된 모듈은 상위 모듈이 참조될 때 Optional 모듈은 참조제외

의존 라이브러리의 경로

• 로컬 : USER_HOME/.m2/repository 에 저장된다.

5. profile

Maven은 서로 다른 환경에 따라 달라지는 설정을 각각 관리할 수 있는 Profile 기능을 제공한다.

6. POM.xml

pom.xml 은 메이븐을 이용하는 프로젝트의 root에 존재하는 xml 파일이다. pom은 프로젝트 객체 모델(Project Object Model)을 뜻한다. 프로젝트 당 1개가 있다. 이것만 보면 프로젝트의 모든 설정, 의존성 등을 알 수 있다!!

엘리먼트

• <groupId> : 프로젝트의 패키지 명칭

• <artifactId> : artifact 이름, groupId 내에서 유일해야 한다.

• <version> : artifact 의 현재버전 ex. 1.0-SNAPSHOT

• <name> : 어플리케이션 명칭

• <packaging> : 패키징 유형(jar, war 등)

• <distributionManagement> : artifact가 배포될 저장소 정보와 설정

• <parent> : 프로젝트의 계층 정보

• <dependencyManagement> : 의존성 처리에 대한 기본 설정 영역

• <dependencies> : 의존성 정의 영역

• <repositories> : 이거 안쓰면 공식 maven 저장소를 활용하지만, 사용하면 거기 저장소를 사용

• <build> : 빌드에 사용할 플러그인 목록을 나열

• <reporting> : 리포팅에 사용할 플러그인 목록을 나열

• <properties> : 보기좋게 관리가능, 보통 버전에 많이 쓴다.

maven multi module project 만드는 방법과 해당 프로젝트를 SVN에 올리고 다른 개발환경에서 checkout하는 방법

모든 환경은 Mac OS 환경입니다.

오늘 설명 할것은 maven multi module project를 만드는 방법과 해당 프로젝트를 svn에 업로드하고 다른 개발환경에서 checkout하는 방법입니다.

1) 우선은 부모 maven 프로젝트를 만들어줍니다.

지금까지 잘 따라오셨다면 부모 maven 프로젝트가 만들어져 있을 것입니다. 주의해야할 점은 반드시 packaging을 pom으로 지정해주셔야하는 것입니다.

2)자식 메이븐 모듈 만들기

이렇게 하면 자식 메이븐 모듈 프로젝트까지 생성이 됩니다.

3)프로젝트 구조

제가 만든 별도의 프로젝트는 신경쓰시지 마시고 , 생성된 부모/자식 메이븐 프로젝트만 참고하시면 됩니다.

4)SVN에 업로드 및 checkout 

svn에 업로드하는 것과 checkout하는 것은 이전 글에 게시되어 있으니 참고바랍니다. 이전 글에서 언급되지 않은 부분만 설명합니다. 우선은 자식프로젝트는 신경쓰시지 마시고 부모프로젝트를 루트로 잡고 team>share project를 해줍니다. 그러면 svn에는 eclipse의 parent 프로젝트의 구조와 동일하게 업로드 됩니다. 그런 다음 다른 개발 환경에서 checkout을 하시면 위의 그림과 동일하게 parent 메이븐 폴더가 생기게 됩니다. 하지만 자식 메이븐 모듈은 보이지 않을 것입니다. 그렇다면 어떻게 자식 모듈을 위의 그림처럼 보이게 할 것인가? checkout받은 parent 프로젝트 밑의 child라는 폴더>우클릭>import>existing projects into workspace 누르시면 위와 같이 자식모듈 프로젝트 구조가 생기게 됩니다.

설명을 중간중간 하지 않았지만 parent/child의 pom.xml을 보시면 자식/부모관계를 명시하는 태그들이 생겨있을 것입니다. 그것은 보시고 구조를 이해하시는 것도 중요할 것같습니다.