多くのファセットと多くの異なる機能を備えた非常に汎用的なアプリケーション用のプラグイン拡張メカニズムを作成したいと思います。
私が開発したものについてもう少し詳しく：
私はEquinox（例として、アプリケーションの制約のために使用できません）と、拡張機能と拡張ポイントを含む非常に優れた拡張性メカニズムを検討しています。このアプローチの問題は何ですか？この問題に対してどのような代替ソリューションが利用できますか？
どんなアプリケーションを書いていますか？拡張機能と拡張ポイントの日食メカニズムは、日食rcpの独自の概念です。したがって、Eclipse rcp guiを作成する場合は、これが最適な方法です。
サーバーアプリケーションを作成する場合は、OSGiサービスの方がはるかに適しています。サーバーアプリケーションの場合、Equinoxの代わりにApacheKarafを使用することをお勧めします。KarafはEquinoxをOSGiフレームワークとして実行できますが、Mavenリポジトリからのデプロイやロギングサポートなどの多くの追加機能も提供します。これは、OSGiとApacheKarafを使用して単純なサーバーアプリケーションを作成する方法の簡単なチュートリアルです。OSGiサービスを使用してAPIと実装を分離する方法を示しています。
拡張性のために、おそらく1つのAPIと複数のサービス実装を使用することをお勧めします。これも可能です。インターフェイスのサービスのリストを取得でき、追加および削除されたサービスの通知を受け取ることもできます。
UIの拡張性については、EclipseRCPは確かにその領域で多くの機能を提供します。
下位層の場合、OSGiを見ているように聞こえますが、Equinoxは単に多くの可能なランタイム環境の1つです。仕様に準拠したコーディングに固執する場合は、Equinox、Felix...またはその他のアプリケーションの実装を使用できます。
拡張性について話すとき、あなたは実際に何を探しているのかを定義していません。そして、そのような自由形式の質問で、あなたはそれを閉じて上昇させています。
OGSiを使用する際に注意すべき問題の1つは、バンドル（=モジュール）ごとにクラスローダーを使用して、バンドルを相互に分離することです。これは、OSGi環境で使用するように設計されていないライブラリを使用する場合は特に、しばしば苦痛になります。最終的に、結果として生じるクラスのロードの問題のほとんどすべてを解決できますが、物事を理解するのにかなりの時間がかかる可能性があります。
また、Springを使用して、プログラムをモジュール化して拡張可能にすることもできます。Springのアプリケーションコンテキストはネストできるため、「モジュール」はその親のSpring Beanを使用できますが、その逆はできません。Springは、クラスパス上のすべてのjarのアプリケーションコンテキストファイルを自動的に検出するように指示できます。このアプローチでEclipse拡張ポイントをモデル化するために、1つのモジュールが、他のモジュールがフックインするために使用できる「レジスタ」メソッドを持つBeanを提供できます。
別のモジュールからサービスを使用するのは、春にサービスBeanへの参照を取得するのと同じくらい簡単です（アプリケーションコンテキスト階層がそれに応じて設定されていると仮定します）。