다중 모듈 프로젝트에서 bom 게시

우리는 약 2000 개의 별도 Java 프로젝트가있는 대기업입니다. 역사적인 이유로 다중 모듈 프로젝트가 없지만이를 소개하고자합니다.다중 모듈 프로젝트에서 bom 게시

논리적으로 이미 프로젝트의 "그룹", 즉 밀접한 관련이있는 50 개의 프로젝트를 담당하는 사람이 이미 있습니다. 이 사람은 정기적으로이 50 개 프로젝트의 최근 일관된 버전을 포함하는 BOM을 게시합니다.

이제이 50 개의 프로젝트를 가져 와서 하나의 대형 다중 모듈 프로젝트에 포함시키는 것이 합리적입니다. 그러나 다른 프로젝트 (그룹 외부)가 일관된 버전을 가져야하므로 BOM을 게시해야합니다.

따라서 요약하면 다중 모듈 프로젝트의 일부인 50 개 프로젝트의 모든 버전을 포함하는 BOM이 필요합니다. 그런 BOM을 만드는 "Maven 방식"이 무엇인지 궁금합니다. 내가 생각할 수있는 것 :

bom은 다중 모듈 프로젝트의 51 번째 프로젝트입니다. 종속성의 버전은 상위 pom의 특성에 의해 설정됩니다.
bom은 다중 모듈 프로젝트에있는 정보에서 생성되어 사이드 아티팩트로 게시됩니다 (이 경우 Maven 플러그인을 작성해야 할 수도 있습니다).

무엇이 좋을까요? 내가 상용 자바 프로젝트의 2K 본 적이 없어, 어떻게 오픈 소스에 내 대답을 기반으로합니다

2017-11-16 JF Meier

프로젝트 란 무엇인가요? 독립 실행 형 응용 프로그램 또는 lib? 그리고 다른 프로젝트 (앱과 라이브러리 모두)에서 libs (그러나 앱이 아닌)를 참조합니까? 그리고 여러 개의 라이브러리를 하나의 프로젝트로 그룹화하고 모두 하나의 엔터티 (BOM)로 게시하려고합니다. –

당신이 가지고있는 것에서 성취하고자하는 것이 정확히 무엇인지 불분명합니다. –

@ ThorbjørnRavnAndersen 분명히하고 싶지만 어떤 부분이 불분명한지 말해 줄 수 있습니까? –

우리는 멀티 모듈 프로젝트에도 BOM을 사용하고 있지만, 해당 모듈의 빌드를 생성하거나 업데이트하지 않습니다.

릴리즈 관리 프로세스가 빌드 모듈 (또는 모듈 그룹)의 배송을 완료 한 경우에만 BOM이 업데이트됩니다. 한 번 전달 된 다음 BOM이 업데이트되어 Nexus로 푸시됩니다 (1.0-SNAPSHOT 버전으로 저장 됨, 지속적으로 BOM을이어서 모노 또는 다중 모듈 프로젝트 우리 POM (내 포함

각 배송) 후에 무시)하고없이 의존성 관리 만 우리 프로젝트를 의미하는 아티펙트 에 따라 대한 버전 사용로부터 종속성 관리 BOM은 다른 종속 모듈의 최신 버전을 제공합니다.

다른 말로하면 릴리스 부분과 빌드 측면 (빌드와 여기에서 완료)을 구분합니다. "BOM"은 전달 된 내용을 나타내며 모든 프로젝트가 함께 잘 작동하는 것으로 확인됩니다 그들은 함께 생산에 전달되었습니다).

출처

2017-11-19 00:08:21 VonC

이 통찰력있는 답변에 감사드립니다. 테스트가 끝나면 BOM 생성을 연기하는 것이 좋습니다 (가능한 경우 : 납품 단계). 그러나이 방법으로 버전을 교환하면 빌드가 불안정해질 수 있으므로 스냅 샷의 "오용"에주의해야합니다 (물론 이것이 분명히 발표되고 거의 발생하지 않는 한). –

@JFMeier 정확하게 : 그래서 내가 레코더를 개발 한 이유입니다. 기본적으로 빌드는 BOM을 사용하지 않고 버전이 설정된 특수 종속성 관리 섹션을 사용합니다. 필요에 따라 기록 된 플러그인은 BOM을 읽고 해당 특수 섹션을 BOM 버전으로 대체합니다. pom.xml은 Git repo에 있기 때문에 해당 플러그인을 호출 할 때마다 기록 된 버전 변경 사항을 추적 할 수 있습니다. 그러나 기본적으로 플러그인은 호출되지 않으며 "특수 종속성 관리 섹션"은 고정 된 버전 세트와 함께 그대로 재사용되어 빌드 안정성을 보장합니다. – VonC

@JFMeier 목표는 질문에 답하는 것입니다. 어떤 버전으로 프로젝트를 구축해야합니까?요구에 따라, 당신은 그 버전을 "현재 배포 된 것"으로 얻을 수 있습니다 (BOM 읽기, pom.xml 수정). 그러나 다른 모든 빌드 인스턴스의 경우 이전에 설정 한 것을 사용하고 있습니다 (다시 : 빌드 안정성) – VonC

작동 :

라이브러리 사람들에 의해 그룹화되어서는 안된다 - 그들이 문제로 그룹화 해야 그들이 해결했다. 종종 오픈 소스 프로젝트에는 여러 libs가 있습니다. Jackson은 jackson-databind, jackson-datatype-jsr310 등입니다. 이러한 라이브러리는 서로 밀접하게 관련되어 있으며 서로에 의존 할 수 있습니다.
이러한 그룹은 너무 커야합니다. 일부 프로젝트는 1, 다른 그룹은 5 또는 10 일 수 있습니다. 그룹의 50 개 라이브러리는 너무 많이 들립니다.
그룹의 라이브러리가 모두 동시에 해제되는 경우 (하나만 업데이트되는 경우에도)이 더 쉽습니다. 이렇게하면 그룹의 여러 lib를 사용하는 앱의 버전을 쉽게 추적 할 수 있습니다.
그룹간에 종속성이 없어야합니다! 그리고 아마도 이것이 가장 중요한 규칙 일 것입니다. 서로 의존하는 라이브러리의 깊은 계층 구조는 이제 허용되지 않습니다. 왜냐하면 이제는 많은 프로젝트와 라이브러리 간의 호환성을 유지해야하기 때문입니다. 이것은 단지 비례하지 않습니다. 즉, libs 사이에서 가끔씩 복사 - 붙여 넣기 코드가있을 것입니다 - 이것은 더 적은 악마입니다.
마지막 규칙 (아마도 모든 곳에서으로 사용되는 lib 일 수도 있음)은 이전 API를 사용하는 프로젝트가 없을 때까지 공용 API의 이전 버전과의 호환성을 유지해야합니다. 이러한 라이브러리는 유지하기가 매우 어려우며 오픈 소스를 사용하는 것이 좋습니다.

독립 실행 형 프로젝트는 이제 동일하거나 다른 그룹의 라이브러리에 의존 할 수 있지만 그룹 내 버전이 동일하므로 속성으로 한 번만 설정하면됩니다.또한 :

당신은 그룹 내에서 부모 리딩 같은 다른 POM 파일에서 <dependencyManagement> 섹션을 가져 허용 <scope>import</scope> 볼 수 있습니다 (어떤 이유로 나를 위해 일한 적이).
또는 xxx-all modules - 그룹 내의 다른 모든 모듈에 의존하는 모듈이므로 의존 할 때 다른 사람에게도 전 달합니다.

출처

2017-11-16 19:30:36

대답 해 주셔서 감사합니다. 그러나 진실은 : 우리 회사는 2000 개의 Java 프로젝트 (항아리, 전쟁 또는 귀를 만드는 각각의 프로젝트)를 가지고 있으며, 대부분은 일종의 라이브러리 (라이브러리를 사용하는 귀 또는 전쟁 중 일부)이며 이미 서로 의존하고 있습니다. 이러한 종속성은 "그룹"(실제로 주제를 기반으로하지만 책임있는 사람이 각각 있음) 내부에 있지만 여러 가지 방법으로 그룹간에 이동합니다. –

우리는이 큰 매듭을 풀 수 없습니다 - 우리는 단지 그것을 관리 할 수 있습니다. 그래서 우리는 한 그룹의 프로젝트를 다중 모듈 프로젝트에 넣기를 원합니다. 그럼에도 불구하고 서로 다른 다중 모듈 프로젝트는 서로간에 다양한 의존성을 가질 것입니다. –

그룹 간 종속성은 어떤 사이클보다 다른 트리 구조를 가지고 있어야합니다. – caot

다중 모듈 프로젝트에서 bom 게시

답변

관련 문제