私は RCP アプリケーションを開発しており、そのために p2 更新も実装しています。
このリンクをガイドとして使用して、 p2 更新を実装しています。
たとえば、アプリケーションに 3 つのプラグイン A、B、および C があります。
プラグイン A は、アプリケーションのコア機能を表します。プラグイン B は、もう 1 つの必須プラグインです。プラグイン C はオプションです。
3 つの機能プロジェクトを作成しました。FeatureA にはプラグイン A と依存ライブラリが含まれています。
FeatureB には、プラグイン B と依存ライブラリが含まれています。FeatureC にはプラグイン C と依存ライブラリが含まれています。
birt、nattable など、これら 3 つのプラグインに共通する特定のライブラリがあります。それらをどのように構成する必要がありますか。現在、各機能プロジェクトに個別に追加しています。機能プロジェクトを構築するためのより良い方法は何ですか? よろしくお願いします。
機能が必要とするプラグインの共通のサブセットがある場合、必要なプラグインを含む別の「要件」機能を作成し、既存の機能でその機能を必要とすることができます。これにより、必要なプラグインのセットを時間の経過とともに簡単に変更できます。
このアプローチの欠点の 1 つは、機能 B が共通機能のすべてのプラグインを必要としない可能性があることです。つまり、機能 A なしで機能 B を出荷すると、意図したよりも多くのプラグインが出荷される可能性があります。
考慮すべきもう 1 つの項目は、機能を互いに独立して更新する予定があるかどうかです。機能のすべてのバージョンを同じにする必要がある場合は、新しい要件機能を用意することは理にかなっています。ただし、機能 B が 1.0 のままで機能 A がバージョン 2.0 にアップグレードできる場合、シングルトン プラグインがあると、プロビジョニングの競合が発生します。
もう 1 つ考えられるのは、RCP を作成しているので、製品ファイルに対してp2 パブリッシャーを実行して、ラインナップ IU を生成することだけが必要な場合があるということです。これにより、RCP アプリケーションのより決定論的なプロビジョニングが生成されます。標準の Eclipse About ダイアログを持たない単純な RCP を作成している場合は、機能を公開する必要さえありません。
最後に、更新機能を購入することもできます。過去 5 年間このテクノロジを書いてきた私は、多くの落とし穴があることをお伝えできます。私の会社の製品であるSecure Delivery Centerは、ソフトウェアの出荷を容易にし、簡単な更新サポートを提供します。