큰 프로젝트를 분할하여 멀티 모듈 Maven 프로젝트 만들기


23

종속성 관리를 위해 Maven을 사용하는 Spring-MVC 애플리케이션을 개발 중입니다. 프로젝트가 크면 프로젝트를 여러 부분으로 분할하려고합니다. 나는 약간의 의문을 가지고 있었으며, 희망적으로 여기에 답을 얻을 것입니다.

현재 ROOT.war서버의 Apache Tomcat에서 와 같이 단일 WAR 파일을 배포하고 있습니다. 프로젝트가 크면 알림 및 이메일, 타사 서비스, PUSH (Cometd), REST API 등과 같은 웹앱에 일부가 있습니다. 현재는 모두 클럽이되어 서로 의존하고 있습니다. 예를 들어, 알림은 사용자에 맞게 조정되므로 Notification개체도 개체에 따라 다릅니다 Person.

큰 프로젝트를 분할하는 주요 목적은 버그 수정, 기능 추가, 테스트 등을 위해 개별 모듈에서 작업 할 수 있도록하는 것입니다. 만족할 경우이 모듈 만 전체 응용 프로그램 대신 서버에서 교체 할 수 있습니다. 이것이 가능한가?

앞에서 이미 언급했듯이 개체간에 종속성과 매핑이 있습니다. 다른 서브 모듈에서 그것들을 어떻게 관리 하거나 수입 명세서 만 다른 프로젝트를 포함하도록 변경됩니까?

내가 말했듯이, 의도는 개별 모듈에서 작업하고 모듈을 배포 할 수 있도록하는 것입니다 (바람직하게는 뜨거운 것). 현재로는 단일 WAR 파일 만 ROOT.war있습니다. 분할하면 여러 war 파일이 생성 되고 URL에서 domain-name.com/module_name/some_mapping?

현재 문서를 확인하고 있지만 이것이 Maven에서 제공하는 멀티 모듈로 달성하고자하는 주요 목표이며 이것이 가능한지 알고 싶습니다. 더 많은 정보가 필요하면 알려주십시오.

현재 봄부터 부모 POM을 다음과 같이 사용하고 있습니다.

<parent>
    <groupId>io.spring.platform</groupId>
    <artifactId>platform-bom</artifactId>
    <version>1.1.3.RELEASE</version>
    <relativePath />
</parent>

1
나는 대답하기 위해 다른 사람들에게 맡깁니다. 아이디어는 매우 건전합니다. dependencyManagement가있는 상위 POM과 Person과 같은 DAO의 jar로 시작할 수 있습니다. 매우 기본적인 도서관. 등등. 물론 순환 종속성은 없습니다.
Joop Eggen

답변:


20

가능합니까?

예 당연 하죠. 나는 과거 구조에서 이와 같은 몇 가지 프로젝트를 가지고 있습니다. 여기서 약간의 시작을 바랍니다.

함께 물건을 짜는 데 사용할 Maven의 두 가지 주요 기능이 있습니다.

나누고 정복

여러 독립 프로젝트로 프로젝트를 분할해야합니다. 여기서 독립적으로 프로젝트 외부의 코드에 대한 모든 참조는 소스 트리를 직접 병합하지 않고 Maven의 종속성을 통해 수행됩니다.

소스 트리의 상태에 따라 많은 작업을 나타낼 수 있습니다. 그것은 당신이 Maven에게 구두를 돌리는 것이 아니라 코드베이스를 구조화하고 살균하는 수단으로 사용한다고 말했습니다. 그것을 도구 상자로 생각하면 훨씬 쉽게 찾을 수 있습니다.

멋진 도구 창고

여기보다 :

좋지 않은 툴 쉐드

Maven은 컨벤션 에 크게 의존 하므로 더 잘 정리할수록 Maven이 더 많은 도움을 줄 수 있습니다. 즉, 자체 컨벤션에 더 잘 맞도록 재구성해야 할 수도 있습니다. 여기에 조언을 제공 해야하는 경우 Maven의 컨벤션보다 Maven의 컨벤션에 맞게 물건을 변경하는 것이 훨씬 쉽습니다. 당신의 컨벤션을 이해하십시오.

이러한 프로젝트를 주 응용 프로그램 외부에서 사용할 수 있으면 실제로 독립적 인 라이브러리로 살 수 있으며 maven 종속성을 포함 할 수 있습니다. 응용 프로그램 소스 트리가 아닌 자체 리포지토리에 있어야하며 기본 응용 프로그램의 일부에 의존해서는 안됩니다.

응용 프로그램의 핵심 부분은 일단 프로젝트로 분할되면 모듈로 구성 할 수 있습니다. 일반적으로 앱의 기본 소스 폴더 하위 폴더로 배치합니다.

또한 앱의 부모 POM에는 모듈 선언이 포함됩니다. 또한 앱에 대한 모든 공통 종속성을 배치하고 대부분의 빌드 플러그인 및 해당 구성을 선언합니다. 여기에서는 모듈에서 재사용 할 수있는 응용 프로그램 버전과 같은 속성 그룹을 배치하는 것이 좋습니다. 모든 것이 동일한 버전을 가지고 있고 한 곳에서 버전을 사용하는 경우 관리하기가 훨씬 쉽습니다.

압형

1보다 큰 팀인 경우 Maven 종속성을위한 저장소를 설치하는 것이 좋습니다. 봐 Artifactory , 넥서스 또는 Archiva . POM 파일을 직접 설치하여 POM 파일을 직접 설치할 수 있도록 구성하면 한 번 실행하면 많은 오버 헤드가 발생하지 않지만 올바른 jar를 사용하여 올바른 위치에있는 종속성을 해결하는 데 많은 시간을 절약 할 수 있습니다.

툴링의 주제에 대한 다음 논리적 단계는 지속적인 통합 시스템입니다 ( Jenkins , 더 많은 것이 있습니다). 테스트를 실행하는 소스를 빌드하고 아티팩트로 밀어 넣는 작업을 처리합니다.이 모든 작업을 수행하면 코드 작업 만 수행하고 나머지는 작동합니다.

war maven 으로 앱을 패키징하기 때문에 jar 파일 또는 기타 유사한 작업을 병합하지 않고도 전쟁 빌드를 처리 하고 모든 종속성을 적절한 위치에 배치 할 수 있으므로 걱정할 필요가 없습니다.

나는 여기에 훨씬 더 오래 갈 수 있지만 좋은 예는 없습니다. github에서 비슷한 규모의 프로젝트를 찾고 pom 파일과 폴더 계층을 어떻게 구축했는지 확인하십시오. 하나 이상의 봐, 일부는 아무도 정말 화신하지, 다른 사람보다 더 나은 설정을 맞는 진실을하지만 당신은 그것을 수행하는 방법에 대한 당신의 생각에 연료를 충분히 찾을 수 있습니다.

가지고 젠킨스를 예를 들면 :

부모 POM 이 상당히 광범위 하다는 것을 알 수 있습니다 .

이 섹션에서 볼 수 있듯이 모듈을 사용합니다.

<modules>
    <module>core</module>
    <module>war</module>
    <module>test</module>
    <module>cli</module>
</modules>

또한 각 모듈은 POM을 포함하는 동일한 이름의 하위 폴더에 해당합니다. 당신이 원하는만큼 중첩 할 수 있지만, 정신 수준 내에서 유지하십시오;).

작은 시작

Maven을 사용한 적이 없다면 모듈을 즉시 시작하지 않는 것이 좋습니다. 천천히 시작하고, 가장 간단한 라이브러리 중 하나를 말하고 maven 프로젝트로 만드십시오. 그런 다음 기본 응용 프로그램을 간단한 maven 프로젝트로 만듭니다. 그 작업이 끝나면 간단한 종속성을 추가 한 다음 첫 번째 모듈 등을 분할하십시오.

Maven은 훌륭한 도구이지만 특히 일이 진행되지 않을 때 목에 심한 통증이 될 수 있습니다. 당신의 첫 번째 여행에서 전체 whammy로 시작하는 것은 재앙을위한 레시피입니다 (나를 위해!).

상황이 조금 이상하면 항상 mvn help:effective-pom명령을 사용 하여 Maven이 실제로 이해 한 것을 볼 수 있습니다.

플러그인

당신의 의견에서 나는 당신이 원하는 것을 더 잘 이해합니다. 이 경우 플러그인 접근 방식을 사용합니다. 작업을 분리하려는 확장 점의 API를 노출하는 프로젝트를 작성하십시오. 그런 다음이를 구현할 새 프로젝트에서이를 종속성으로 사용할 수 있습니다. 기본 응용 프로그램 에서이 구현에 대한 적절한 종속성을 추가하면 (이번에는 maven 모듈을 사용하지 않음) 계속 진행해야합니다. 결국 주요 응용 프로그램 프로젝트는 외부 프로젝트에서 수행되고 종속성을 통해로드되는 모든 소스 코드를 거의 전달하지 않습니다.

종속성이 전쟁에서 정적으로 빌드되었으므로 핵심이 변경되었는지 여부에 관계없이이 방법으로 전체 애플리케이션을 다시 배치해야합니다. 실제보다 최악의 소리가납니다. 실제로 새로운 변경 사항 만 실제로 빌드되고 나머지는 기본적으로 이전 jar의 사본입니다. 그러나 모든 것이 war 파일에 있으므로 서버를 다시 빌드하고 서버를 중지했다가 다시 시작해야합니다.

더 나아갈 필요가 있다면 불가능하지는 않지만 조금 더 복잡해집니다. OSGI를 살펴 보는 것이 좋습니다 . 다른 구현도 있지만 Apache Felix 를 사용하면 시작할 수 있습니다. 이를 통해 외부 항아리를 가져 와서 적절한 플러그인으로 만들 수 있습니다. 동적 재로드 및 업데이트의 문을 여는 구성 요소의 런타임 수명주기를 훨씬 더 많이 제어 할 수 있습니다. 그러나 코어에 대한 주요 변경 사항이 다시 필요하므로 아마도 좋은 출발점이 아닐 것입니다. 그러나 프로젝트가 잘 분리되어 있고 원하는대로 모든 부품을 분리 한 후에는 업데이트시 응용 프로그램을 시작하고 중지하는 것이 자연스럽게 다음 단계가 될 수 있습니다.

모듈과 종속성의 기본 차이점은 다음과 같습니다.

  • 모듈은 기본적으로 하위 응용 프로그램과 같은 기본 응용 프로그램과 동일한 소스 트리에 있습니다.
  • 종속성은 어디에나있을 수 있습니다.

여기서 성경을 찾을 수 있습니다 .

이것이 도움이되기를 바랍니다. 행운.


실제로 소스 트리 대신 maven을 통해 모듈을 번들링하면 많은 질문이 해결되었습니다. 그러한 프로젝트의 배포에 대해 알려주십시오. 우리가 고려하고있는 다른 이유 중 하나는 개발자가 필요한 모듈을 작업하고 실시간으로 변경할 수 있기 때문입니다. 우리가 피하고 싶은 한 가지는 코어 모듈 이외의 다른 응용 프로그램 서버를 중지하고 다시 시작하는 것입니다. 내가 생각할 수있는 2 개의 모듈로 자주 변경되는 코드가 포함됩니다. 우리는 Tomcat을 응용 프로그램 서버로 사용하며 Apache에서로드 밸런싱되었습니다. 고맙습니다.
우리는 Borg

Maven 모듈은 종종 기본 응용 프로그램과 동일한 소스 트리에 있습니다. 소스 트리 외부에서 maven 모듈을 사용하는 것은 실제로 가치보다 복잡합니다. 소스 트리 외부에서 프로젝트를 호스팅하는 경우 일반 독립 프로젝트로 이동하여 일반 종속성을 사용하십시오.
Newtopian

우리는 Maven 의존성으로 직접 프로젝트의 일부를 추가 할 것이라고 생각합니다. 이런 식으로 프로젝트의 일부를 직접 작업 할 수 있습니다. 하위 프로젝트 중 하나를 POM.xml의 종속성으로 버전 2.0.0이라고 말한 다음 약간의 변경 사항이 있으면 모듈의 2.0.1을 sonatype으로 푸시합니다. 코어 모듈에 2.0.1로 가라고 지시하면 ROOT.war 내부의 POM.xml을 변경하고 ROOT 디렉토리를 삭제하는 것으로 충분합니다. 주요 목적은 서버를 중지하지 않는 것입니다. 고맙습니다.
우리는 Borg

pom.xml은 전쟁이 생성 된 후에 전혀 관련이 없습니다. 즉 Tomcat (또는 사용하는 컨테이너)은이 파일을 사용하지 않습니다. 이 파일은 Maven에서 새 war 파일을 작성하는 데 사용되며이 파일을 서버에 배치해야합니다. 따라서주기는 코드 작업, jar 파일 작성, 전쟁 POM의 버전 업데이트, war 파일 작성, 새 war 파일로 서버 업데이트입니다. 일부 서버는 일반적으로 몇 초 동안 응용 프로그램을 끄는 암시적인 재배치를 지원합니다.
Newtopian
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.