메이븐 부모 폼 vs 모듈 폼
멀티프로젝트 빌드에서 부모 POM을 구조화하는 방법은 여러 가지가 있는 것 같습니다만, 각각의 장점과 단점이 무엇인지에 대해 생각하신 분은 없습니까?
부모 폼을 갖는 가장 간단한 방법은 이를 프로젝트의 루트에 넣는 것입니다.
myproject/
myproject-core/
myproject-api/
myproject-app/
pom.xml
여기서 pom.xml은 부모 프로젝트일 뿐만 아니라 -core -api 및 -app 모듈도 설명합니다.
다음 방법은 부모 디렉토리를 다음과 같이 자신의 서브 디렉토리로 분리하는 것입니다.
myproject/
mypoject-parent/
pom.xml
myproject-core/
myproject-api/
myproject-app/
부모 POM에 모듈이 포함되어 있지만 상대적인 경우(예: /myproject-core)
마지막으로 모듈 정의와 부모를 다음과 같이 분리하는 옵션이 있습니다.
myproject/
mypoject-parent/
pom.xml
myproject-core/
myproject-api/
myproject-app/
pom.xml
부모 pom에는 "공유" 구성(dependency Management, properties 등)이 포함되어 있고 myproject/pom.xml에는 모듈 목록이 포함되어 있습니다.
그 목적은 대규모 빌드로 확장 가능하기 때문에 다수의 프로젝트 및 아티팩트로 확장 가능해야 합니다.
몇 가지 보너스 질문:
- 는 소스 제어, 도입 디렉토리, 공통 플러그인 등 다양한 공유 구성을 정의하는 최적의 장소입니다(부모를 상정하고 있습니다만, 이것에 자주 시달리고 있어, 공통의 것이 아닌 각 프로젝트에 사용되고 있습니다).
- maven-release 플러그인, hudson 및 nexus는 멀티프로젝트 셋업 방법에 대해 어떻게 대처합니까(아마도 큰 의문일 수 있습니다).
편집: 각 서브프로젝트에는 각각 독자적인 pom.xml이 있습니다.간결하게 유지하기 위해 생략했습니다.
이 질문에 답하기 위해서는 프로젝트 라이프 사이클과 버전 관리 측면에서 생각할 필요가 있다고 생각합니다.즉, 부모 POM은 그 자체의 라이프 사이클을 가지고 있습니까?즉, 다른 모듈과 분리하여 출시할 수 있습니까?
답변이 "예"인 경우(이것이 질문이나 코멘트에서 언급된 대부분의 프로젝트의 경우), 부모 POM은 VCS와 Maven의 관점에서 자체 모듈을 필요로 하며 VCS 수준에서 다음과 같은 결과가 발생합니다.
root
|-- parent-pom
| |-- branches
| |-- tags
| `-- trunk
| `-- pom.xml
`-- projectA
|-- branches
|-- tags
`-- trunk
|-- module1
| `-- pom.xml
|-- moduleN
| `-- pom.xml
`-- pom.xml
로 인해 체크 , 은 '체크 아웃'을 사용하는 입니다.svn:externals를 들어, '어울리다'를 붙입니다trunks★★★★★★★★★★★★★★★★★★:
root
|-- parent-pom
| |-- branches
| |-- tags
| `-- trunk
| `-- pom.xml
|-- projectA
| |-- branches
| |-- tags
| `-- trunk
| |-- module1
| | `-- pom.xml
| |-- moduleN
| | `-- pom.xml
| `-- pom.xml
`-- trunks
다음과 같은 외부 정의:
parent-pom http://host/svn/parent-pom/trunk
projectA http://host/svn/projectA/trunk
★★★★★의 trunks그러면 다음 로컬 구조(패턴 #2)가 생성됩니다.
root/
parent-pom/
pom.xml
projectA/
'어울리다'를 붙일 수도 있습니다.pom.xml trunks★★★★★★★★★★★★★★★★★★:
root
|-- parent-pom
| |-- branches
| |-- tags
| `-- trunk
| `-- pom.xml
|-- projectA
| |-- branches
| |-- tags
| `-- trunk
| |-- module1
| | `-- pom.xml
| |-- moduleN
| | `-- pom.xml
| `-- pom.xml
`-- trunks
`-- pom.xml
★★★★★★★★★★★★★★★★★.pom.xml는 "짝퉁" 폼의 일종입니다.이 파일은 공개되지 않았고, 이 파일은 공개되지 않았기 때문에 실제 버전은 포함되어 있지 않으며, 모듈 목록만 포함되어 있습니다., 「패턴 의 ( 「패턴 #3」)가.
root/
parent-pom/
pom.xml
projectA/
pom.xml
이 "핵"을 통해 체크 아웃 후에 원자로를 원점에서 가동할 수 있어 더욱 편리해집니다.실제로 대규모 빌드를 위한 maven 프로젝트와 VCS 저장소를 설정하는 방법은 다음과 같습니다. 즉, 작동만 하고 확장성이 뛰어나며 필요한 모든 유연성을 제공합니다.
만약 아니라고 대답한다면 (처음 질문으로 돌아가면) 패턴 #1을 가지고 살 수 있다고 생각합니다.
이제 보너스 질문에 대해 설명하겠습니다.
- 는 소스 제어, 도입 디렉토리, 공통 플러그인 등 다양한 공유 구성을 정의하는 최적의 장소입니다(부모를 상정하고 있습니다만, 이것에 자주 시달리고 있어, 공통의 것이 아닌 각 프로젝트에 사용되고 있습니다).
솔직히 여기서 일반적인 답변을 하지 않을 수 없다('사물을 상호화하는 것이 타당하다고 생각하는 수준을 사용한다' 등).어쨌든 하위 POM은 상속된 설정을 항상 재정의할 수 있습니다.
- maven-release 플러그인, hudson 및 nexus는 멀티프로젝트 셋업 방법에 대해 어떻게 대처합니까(아마도 큰 의문일 수 있습니다).
내가 사용하는 설정은 잘 작동하며 특별히 언급할 것은 없다.
maven-release-plugin)에 .<parent>를 참조해 주세요.릴리스 시 스냅샷 의존 관계를 가질 수 없습니다.이것은 닭이나 달걀 문제처럼 들리지만 나는 그것이 효과가 있는지 기억할 수 없고 그것을 테스트하는 것이 너무 귀찮았다.
내 경험과 메이븐의 베스트 프랙티스에 따르면 두 가지 종류의 "parent poms"가 있습니다.
"company" parent pom - 이 pom에는 모든 pom을 상속하고 복사할 필요가 없는 회사 고유의 정보와 구성이 포함되어 있습니다.다음 정보가 있습니다.
- 저장소
- 유통관리부문
- 공통 플러그인 구성(메이븐 스위칭 소스 및 타깃 버전 등)
- 조직, 개발자 등
이 parent pom을 준비하는 것은 주의할 필요가 있습니다. 왜냐하면 당신의 모든 pom이 그것으로부터 상속되기 때문에 이 pom은 성숙하고 안정적이어야 합니다(parent pom 버전을 출시하는 것은 당신의 모든 회사 프로젝트를 출시하는 데 영향을 미치지 않습니다).
- 두 번째 종류의 부모 폼은 다중 모듈 부모입니다.첫 번째 솔루션을 선호합니다.이것은 다중 모듈 프로젝트의 기본 maven 규약으로, VCS 코드 구조를 나타내는 경우가 많습니다.
그 목적은 대규모 빌드로 확장 가능하기 때문에 다수의 프로젝트 및 아티팩트로 확장 가능해야 합니다.
뮤트립프로젝트는 나무의 구조를 가지고 있기 때문에 당신은 부모 폼의 한 단계까지 내려가지 않습니다.니즈에 맞는 프로젝트 스트럿을 찾아보세요.전통적인 예로는 뮤티모듈 프로젝트를 분리하는 방법을 들 수 있습니다.
distibution/
documentation/
myproject/
myproject-core/
myproject-api/
myproject-app/
pom.xml
pom.xml
몇 가지 보너스 질문:
- 는 소스 제어, 도입 디렉토리, 공통 플러그인 등 다양한 공유 구성을 정의하는 최적의 장소입니다(부모를 상정하고 있습니다만, 이것에 자주 시달리고 있어, 공통의 것이 아닌 각 프로젝트에 사용되고 있습니다).
이 구성은 "회사" 부모 폼과 프로젝트 부모 폼으로 현명하게 분할되어야 합니다.모든 프로젝트와 관련된 것은 "회사" 부모에게 전달되고, 현재 프로젝트와 관련된 것은 자신의 프로젝트에 보내집니다.
- maven-release 플러그인, hudson 및 nexus는 멀티프로젝트 셋업 방법에 대해 어떻게 대처합니까(아마도 큰 의문일 수 있습니다).
회사 부모 폼이 먼저 출시되어야 합니다.멀티프로젝트의 경우 표준 규칙이 적용됩니다.프로젝트를 올바르게 구축하려면 CI 서버가 모두 알고 있어야 합니다.
독립적 부모는 분리되지 않은 구성 요소 간에 구성 및 옵션을 공유하는 데 가장 적합합니다.Apache는 법적 고지사항과 몇 가지 일반적인 패키지 옵션을 공유하는 부모 폼 프로젝트를 가지고 있습니다.
javadoc의 집약이나 릴리스 패키징 등, 톱 레벨의 프로젝트에 실제의 작업이 포함되어 있는 경우는, 그 작업에 필요한 설정과 부모를 개입시켜 공유하는 설정이 경합합니다.부모 전용 프로젝트는 그것을 회피합니다.
공통 패턴(현재로서는 #1을 무시함)은 코드가 있는 프로젝트에서는 상위 프로젝트를 상위 프로젝트로 사용하고 상위 프로젝트를 상위 프로젝트로 사용하는 것입니다.이것에 의해, 코어 데이터를 모두가 공유할 수 있지만, #2에 기재되어 있는 문제는 회피할 수 있습니다.
상위 구조가 디렉터리 구조와 같지 않으면 사이트 플러그인이 매우 혼란스러워집니다.애그리게이트 사이트를 구축하려면 이 문제를 피하기 위해 약간의 조작이 필요합니다.
세 번째 접근법에는 작은 문제가 하나 있습니다.Aggregate POM(myproject/pom.xml)에는 일반적으로 부모가 없기 때문에 설정을 공유하지 않습니다.즉, 모든 집약 POM에는 기본 저장소만 있습니다.
Central에서 플러그인만 사용하는 경우에는 문제가 되지 않지만 내부 저장소에서 plugin:goal 형식을 사용하여 플러그인을 실행하면 실패합니다.예를 들어 다음과 같이 할 수 있습니다.foo-maven-plugingroupId를 사용하여org.example목표 제공generate-foo. 프로젝트 루트에서 다음과 같은 명령을 사용하여 실행하려고 하면mvn org.example:foo-maven-plugin:generate-foo집약 모듈에서는 실행되지 않습니다(호환성 노트 참조).
몇 가지 해결 방법이 있습니다.
- Maven Central에 플러그인을 배포합니다(항상 가능한 것은 아닙니다).
- 모든 집약 POM에서 저장소 섹션을 지정합니다(DRY 원칙을 깨십시오).
- 이 내부 저장소는 settings.xml(~/.m2/settings.xml의 로컬 설정 또는 /conf/settings.xml의 글로벌 설정)에서 구성합니다.이러한 settings.xml을 사용하지 않으면 빌드가 실패합니다(사외에서 빌드해서는 안 되는 대규모 사내 프로젝트에서는 문제가 없습니다).
- 집약 POM에 저장소 설정이 있는 부모를 사용합니다(부모 POM이 너무 많을 수 있음).
언급URL : https://stackoverflow.com/questions/1992213/maven-parent-pom-vs-modules-pom
'source' 카테고리의 다른 글
| -j4 또는 -j8과 함께 make 사용 (0) | 2022.08.27 |
|---|---|
| while(1)과 while(2) 중 어느 쪽이 빠릅니까? (0) | 2022.08.27 |
| Vuex 모듈에서 "뒤틀림"을 방지하기 위해 어떤 이름을 사용합니까? (0) | 2022.08.27 |
| webpack-simple Vue.js 템플릿에서 콘솔에서 Vue 앱에 액세스하는 방법은 무엇입니까? (0) | 2022.08.21 |
| Java에서 HTTP 요청을 보내는 방법 (0) | 2022.08.21 |