(큰) Java 앱을 모듈화하는 방법은 무엇입니까?

Question

다소 대규모 (여러 MLOC) 응용 프로그램이있어보다 관리 가능한 별도의 부품으로 나누고 싶습니다. 현재이 제품은 약 40 개의 이클립스 프로젝트로 구성되어 있으며, 그 중 다수는 상호 의존성이 있습니다. 이것만으로도 지속적인 빌드 시스템은 불가능합니다. 각 체크인마다 매우 재건되어야하기 때문입니다.

"모범 사례"방법이 있습니까?

• 즉시 분리 할 수있는 부품을 식별하십시오
• 상호 의존성을 시각적으로 문서화합니다
• 기존 코드를 풀습니다
• "패치"처리 라이브러리에 신청해야합니다 (실제 라이브러리 앞에 클래스 경로에 넣어서 처리해야합니다)

이를 지원할 (무료/오픈) 도구가 있다면 포인터에 감사드립니다.

Maven에 대한 경험이 없지만 매우 모듈 식 디자인을 강요하는 것처럼 보입니다. 나는 이것이 반복적으로 개조 할 수있는 것인지 또는 사용하는 프로젝트가 처음부터 모듈 식을 염두에두고 레이아웃을 해야하는지 궁금합니다.

2009-07-10 편집

우리는 아파치 개미/아이비. Maven만큼 많은 것을 강요하지 않는 정말 도움이되고 잘 설계된 도구.

나는 우리가 왜 내 블로그에서 그 일을하는지에 대한 좀 더 일반적인 세부 사항과 개인적인 의견을 적었다 - 여기에 게시하기에는 너무 길고 모든 사람에게 흥미롭지 않을 수도 있으므로 자신의 재량에 따라 따르십시오. www.danielschneller.com

Answer 1

사용 오지 당신에게 적합 할 수 있습니다. 응용 프로그램에서 모듈을 만들 수 있습니다. 더 나은 방식으로 의존성을 구성 할 수도 있습니다. 다른 모듈 간의 인터페이스를 올바르게 정의하면 체크인에 영향을받는 모듈을 재구성해야하므로 연속 통합을 사용할 수 있습니다.

OSGI가 제공하는 메커니즘은 기존 코드를 풀도록 도와줍니다. 클래스로드가 작동하는 방식으로 인해 패치를 더 쉽게 처리하는 데 도움이됩니다.

Wikipedia에서 볼 수 있듯이 당신과 잘 어울리는 Osgi의 일부 개념 :

프레임 워크는 개념적으로 다음 영역으로 나뉩니다.

• 번들 - 번들은 추가 매니페스트 헤더가있는 일반적인 항아리 구성 요소입니다.
• 서비스-서비스 계층은 POJO (Plain Old Java Objects)를위한 게시 찾기 결합 모델을 제공하여 번들을 역동적 인 방식으로 연결합니다.
• 서비스 레지스트리 - 관리 서비스를위한 API (ServiceRegration, Servicetracker 및 ServiceReference).
• 수명주기 - 수명주기 관리를위한 API (설치, 시작, 중지, 업데이트 및 번들 제거).
• 모듈 - 캡슐화 및 종속성 선언을 정의하는 계층 (번들이 코드를 가져오고 내보내는 방법).
• 보안 - 번들 기능을 사전 정의 된 기능으로 제한하여 보안 측면을 처리하는 계층.

Answer 2

첫째 : 행운을 빌고 좋은 커피. 둘 다 필요합니다.

한 번은 비슷한 문제가있었습니다. org.example.pkg1.a와 같은 다른 패키지의 클래스 사이에서도 끔찍한 원형 종속성을 가진 레거시 코드는 org.example.pk2.b에 따라 다릅니다. 그리고 그 반대도 마찬가지입니다.

나는 Maven2와 Fresh Eclipse 프로젝트로 시작했습니다. 먼저 가장 일반적인 기능 (로깅 레이어, 공통 인터페이스, 공통 서비스)을 식별하고 Maven 프로젝트를 만들려고했습니다. 나는 부분에 만족할 때마다 라이브러리를 Central Nexus 저장소에 배치하여 다른 프로젝트에서 거의 즉시 사용할 수 있도록했습니다.

그래서 나는 천천히 레이어를 통해 일했습니다. Maven2는 종속성을 처리했으며 M2Eclipse 플러그인은 유용한 종속성보기를 제공했습니다. BTW- 이클립스 프로젝트를 Maven 프로젝트로 변환하는 것은 일반적으로 어렵지 않습니다. M2Eclipse는 귀하를 위해 수행 할 수 있으며 SRC/Main/Java와 같은 몇 가지 새로운 폴더를 만들고 소스 폴더의 빌드 경로를 조정하면됩니다. 1 ~ 2 분 만 소요됩니다. 그러나 프로젝트가 Eclipse 플러그인 또는 RCP 응용 프로그램이고 Maven이 아티팩트를 관리 할뿐만 아니라 애플리케이션을 구축하고 배포하려는 경우 더 많은 어려움을 기대합니다.

Eclipse, Maven 및 Nexus (또는 다른 Maven 저장소 관리자)가 시작하기에 좋은 기초입니다. 당신은 운이 좋고, 시스템 아키텍처에 대한 좋은 문서가 있다면 그리고 이 아키텍처는 실제로 구현되었습니다.)

Answer 3

작은 코드 기반 (40 KLOC)에서 비슷한 경험을했습니다. ° 규칙이 없습니다 ":

• 편집 그리고 "모듈"이 없으면 사용이라는 것을 알기 위해
• "리프 모듈"에서 시작하여 다른 종속성이없는 모듈
• 나는 주기적 종속성을 처리했다 (이것은 매우 오류가 발생하기 쉬운 작업이다)
• Maven을 사용하면 CI 프로세스에 배치 할 수있는 문서 (보고서)가 많이 있습니다.
• Maven을 사용하면 항상 NetBeans (
  아주 좋은 지시 그래프)
• Maven을 사용하면 Codebase에서 라이브러리 코드를 가져오고 소스 패치를 적용하고 제품으로 컴파일 할 수 있습니다 (때로는 매우 쉽습니다. 때로는 매우 어렵습니다).

의존성 분석기도 확인합니다.
_{(원천: javalobby.org)}

netbeans :

_{(원천: Zimmer428.net)}

Answer 4

Maven은 기존 시스템으로 마이그레이션하는 것이 고통 스럽습니다. 그러나 많은 어려움없이 100 개 이상의 모듈 프로젝트에 대처할 수 있습니다.

Answer 5

가장 먼저 결정해야 할 것은 어떤 인프 구조로 이동할 것인지입니다. 독립적으로 유지 관리 된 모듈 (개별 Eclipse 프로젝트로 변환)이 많거나 전체적으로 버전으로 배치 된 단일 코드 덩어리로 간주 할 것입니다. 첫 번째는 Maven과 같은 빌드 환경으로 마이그레이션하는 데 적합합니다. 후자는 모든 소스 코드를 한 번에 보유하고 있습니다.

어쨌든 지속적인 통합 시스템을 실행해야합니다. 첫 번째 작업은 코드 기반을 자동으로 빌드하여 CI 시스템이 소스 저장소를 감시하고 상황을 변경할 때 재 구축 할 수 있도록하는 것입니다. 나는 여기서 메이블이 아닌 접근 방식을 결정했고, 우리는 쉬운 일식 환경을 갖는 데 중점을 두어 Ant4eclipse 및 팀 프로젝트 세트 파일 (어쨌든 사용)을 사용하여 빌드 환경을 만들었습니다.

다음 단계는 원형 의존성을 제거하는 것입니다. 이렇게하면 빌드를 더 간단하게 만들고 일식 경고를 제거하고 결국 "체크 아웃, 한 번 컴파일, 실행"단계로 이동할 수 있습니다. 시간이 걸릴 수 있습니다. 외부 프로젝트 외부 프로젝트는 프로젝트 내부의 코드로 여전히 작동합니다.

파일을 이동하고 기록을 유지할 수있는 소스 저장소의 혜택을 누릴 수 있습니다. 이와 관련하여 CVS는 매우 약합니다.

Answer 6

레거시 소스 코드베이스에는 Maven을 추천하지 않습니다. 그것은 당신에게 모든 것을 조정하기 위해 많은 두통을 줄 수 있습니다.

필요한 것은 프로젝트의 건축 레이아웃을하는 것이라고 생각합니다. 도구가 도움이 될 수 있지만 가장 중요한 부분은 모듈의 논리적보기를 구성하는 것입니다.

Answer 7

무료는 아니지만 구조 101 모든 총알 포인트를 치기위한 도구 지원 측면에서 얻을 수있는만큼 좋은 것을 줄 것입니다. 그러나 레코드의 경우 편견이 있으므로 Sonarj와 Lattix도 확인하고 싶을 수도 있습니다. ;-)