P2를 구현하는 동안 구조 플러그인 및 종속 라이브러리

Question

RCP 응용 프로그램을 개발 중이고 이에 대한 p2 업데이트를 구현 중입니다.

p2 업데이트를 구현하기 위해 가이드로 this 링크를 사용하고 있습니다.

예를 들어, 내 응용 프로그램에는 3 개의 플러그인 A, B 및 C가 있습니다.

여기서 플러그인 A는 내 응용 프로그램의 핵심 기능을 나타냅니다. 플러그인 B는 필수 플러그인입니다. 플러그인 C는 선택 사항이지만.

3 가지 기능 프로젝트를 만들었습니다. FeatureA에는 플러그인 A와 종속 라이브러리가 들어 있습니다.

FeatureB에는 플러그인 B 및 종속 라이브러리가 포함되어 있습니다. FeatureC에는 플러그인 C 및 종속 라이브러리가 포함되어 있습니다.

이러한 3 가지 플러그인에서 공통적으로 사용되는 특정 라이브러리가 있습니다. 흙, nattable. 어떻게 구조화해야합니까? 현재 각 기능 프로젝트에 개별적으로 추가하고 있습니다. 기능 프로젝트를 구성하는 더 좋은 방법은 무엇입니까? 친절하게 안내 해줍니다.

Answer 1

기능에 필요한 플러그인의 공통 하위 집합이있는 경우 필요한 플러그인을 포함하는 다른 '요구 사항'기능을 만든 다음 기존 기능에 해당 기능을 요구할 수 있습니다. 이렇게하면 시간이 지남에 따라 필요한 플러그인 세트를 쉽게 변경할 수 있습니다.

피쳐 B는 피쳐 A가없는 피쳐 B를 발송할 경우 의도 한 것보다 더 많은 플러그인을 제공 할 수 있다는 것을 의미합니다.

고려해야 할 또 다른 항목은 서로 독립적으로 기능을 업데이트 하시겠습니까? 모든 기능 버전이 동일해야하는 경우 새 요구 사항 기능을 사용하는 것이 좋습니다. 그러나 기능 B가 1.0으로 유지되는 동안 기능 A가 버전 2.0으로 업그레이드 할 수 있으면 독점 플러그인이있는 경우 프로비저닝 충돌이 발생합니다.

RCP를 작성하기 때문에 제품 파일에 p2 publisher을 실행하여 라인업 IU를 생성 할 수 있습니다. 이렇게하면 RCP 응용 프로그램을 훨씬 더 결정 론적으로 프로비저닝 할 수 있습니다. 표준 Eclipse About 대화 상자가없는 간단한 RCP를 작성하는 경우 기능을 노출 할 필요조차 없습니다.

마지막으로 업데이트 기능을 구입할 수 있습니다. 지난 5 년 동안이 기술을 작성함으로써 많은 함정이 있다는 것을 알 수 있습니다. 우리 회사의 제품인 Secure Delivery Center을 사용하면 소프트웨어를 쉽게 출하 할 수 있으며 간단한 업데이트 지원이 포함됩니다.