대규모 Maven 프로젝트를 위한 저장소 레이아웃

Question

다음과 유사한 구조를 사용하는 대규모 애플리케이션(~50개 모듈)이 있습니다.

• 애플리케이션
  • 통신 모듈
    • 컬러 통신 모듈
    • SSN 통신 모듈
    • 등.통신 모듈
  • 라우터 모듈
  • 서비스 모듈
    • 투표 서비스 모듈
      • 투표용 웹 인터페이스 서브모듈
      • 투표를 위한 투표 수집기 서브 모듈
      • 등.투표를 위해
    • 퀴즈 서비스 모듈
    • 등.기준 치수

Maven과 Subversion으로 애플리케이션을 가져오고 싶습니다.몇 가지 연구 끝에 나는 이에 대한 두 가지 실용적인 접근 방식이 있다는 것을 발견했습니다.

하나는 이전과 마찬가지로 트리 구조를 사용하고 있습니다.이 구조의 단점은 다중 모듈 보고가 Maven과 잘 작동하도록 하려면 수많은 조정/해킹이 필요하다는 것입니다.또 다른 단점은 Subversion에서 표준 트렁크/태그/분기 접근 방식이 저장소에 훨씬 더 복잡하다는 것입니다.

다른 접근 방식은 상위 프로젝트가 하나만 있고 모든 모듈, 하위 모듈 및 하위 모듈의 일부가 상위 프로젝트의 직접적인 하위인 평면 구조를 사용합니다.이 접근 방식은 보고에 적합하고 Subversion에서 더 쉽습니다. 그러나 이 방법으로 구조가 약간 손실되는 것 같습니다.

장기적으로 어떤 방법을 선택하시겠습니까? 그리고 그 이유는 무엇입니까?

Answer 1

우리는 대규모 애플리케이션(각 번들이 Maven 모듈인 160개 이상의 OSGi 번들)을 보유하고 있으며 우리가 배웠고 계속 배우고 있는 교훈은 플랫이 더 좋다는 것입니다.계층 구조의 인코딩 의미론의 문제점은 유연성을 잃는다는 것입니다.오늘 "통신"이라고 100% 말하는 모듈은 내일 부분적으로 "서비스"가 될 수 있으며, 그런 다음 저장소에서 항목을 이동해야 하며 이로 인해 모든 종류의 스크립트, 문서, 참조 등이 손상됩니다.

따라서 나는 평면 ​​구조를 권장하고 의미 체계를 다른 위치(예: IDE 작업 공간 또는 문서)에서 인코딩하는 것을 권장합니다.

버전 제어 레이아웃에 대한 질문에 좀 더 자세히 답변했습니다. 다른 질문에 대한 예와 함께, 귀하의 상황과 관련이 있을 수 있습니다.

Answer 2

내 생각에는 디렉토리 구조를 평면화하는 것이 더 낫다고 생각합니다.아마도 모든 프로젝트를 볼 때 보기 좋게 정렬되도록 디렉토리에 대한 명명 규칙을 만들고 싶을 수도 있지만 궁극적으로는 추가 계층 구조가 모두 필요하다고 생각하지 않습니다.

Eclipse를 IDE로 사용한다고 가정하면 일단 프로젝트를 가져오면 모든 프로젝트가 단순 목록으로 끝나게 되므로 추가 하위 디렉터리에서 실제로 아무것도 얻을 수 없습니다.추가 계층 구조 없이 구성이 훨씬 간단하다는 사실 외에도 내 마음 속에 선택이 매우 명확해졌습니다.

일부 모듈을 결합하는 것을 고려할 수도 있습니다.나는 귀하의 앱이나 도메인에 대해 아무것도 모르지만 많은 리프 수준 모듈이 다른 최상위 모듈 내부의 패키지 또는 패키지 세트로 더 적합할 수 있는 것 같습니다.나는 항아리를 응집력있게 유지하는 데 전념하지만 때로는 너무 멀리 갈 수 있습니다.