Open-Closed Principleに沿って、私は通常、汎用的な「インターフェース」または「API」パッケージ/ライブラリと 1 つ以上の実装 (JDBC などの多くの一般的な API と非常によく似ています) が存在するように、Java パッケージとライブラリを設計します。または JAXP/SAX)。OCP に違反せずにベース API ライブラリ内の実装 (または場合によっては複数の実装) を見つけるために、私は通常 Java のServiceLoaderメカニズムを使用するか、場合によってはClassGraphやReflectionsなどのサードパーティ ライブラリを介してクラスパス スキャンを使用します。Maven の観点からは、実装はruntime依存関係として取り込まれます (実行時にのみ必要で、コンパイル時には必要ないため)。かなり標準的なもの。
そこで、これらのパッケージの一部を OSGi バンドルとして (API と実装を別々のバンドルで) 利用できるようにしたいと考えていますが、OSGi では各バンドルに独自のクラス ローダーがあるため、クラスパス スキャンもServiceLoaderAPI もこの目的には機能しません。一見すると、OSGi の「フラグメント」メカニズムは、上記のプレーン Java セットアップに最も近いように見えます。そのシナリオでは、API バンドルが「フラグメント ホスト」になり、具体的な実装がそのホスト バンドルにフラグメントとしてアタッチされます。フラグメント ホストとそれに接続されているすべてのフラグメントは同じクラス ローダーを使用するため、標準のプレーン Java メカニズムは次のようになります。ServiceLoaderまたは ClassGraph はおそらくまだ機能します。これには、ライブラリ/バンドルが OSGi コンテキストで実行されているかどうかを検出する必要がなく、OSGi フレームワークの依存関係が必要ないという利点もあります。
つまり、一言で言えば、私の質問は次のとおりです。OSGi でランタイムのみの依存関係を実装する正しい方法はフラグメントですか、それともより良い (またはより標準的な) 方法はありますか? できれば、OSGi コンテナーで動作するが、OSGi 自体への依存を必要としないソリューションを探しています。