2

OSGi でコンポーネントを接続するプロセスは、時間の経過とともに進化したようです。

進行は以下のようです。

非常に多くの異なるライブラリとアプローチがあるため、選択肢を合理的なアプローチに絞り込む方法が必要です。テクノロジーが同じ問題に対する重複したアプローチであるか、相互に構築されているかはわかりません。

私は次のものを使用することを知っています：

  • アパッチ・フェリックス
  • アパッチスリング
  • メイヴン

それ以上に、重複することなくバンドルを作成するための簡単な手法が必要です。

これは、maven と次のプラグインを使用して作成したバンドルのスクリーンショットです: maven-bundle-plugin、maven-scr-plugin。

OSGi バンドル

多くの冗長性に気づき、何が必要かわかりません。

  1. pom.xml pom.xml が jar に含まれているのはなぜですか? OSGi は、OSGi バンドル リポジトリ (OBR) から依存関係をプルするためにこれを必要としますか?

  2. MANIFEST.MF これも依存関係をリストし、serviceComponents.xml を参照します Service-Component: OSGI-INF/serviceComponents.xml

  3. serviceComponents.xml は、SCR 注釈の XML 表現を使用したマニフェストの拡張のようです。この時点で、Java クラスの SCR アノテーションは無関係ですか、それとも OSGi はこの XML を使用してアノテーション付きのクラスを検索しますか? iPojo を使用した場合、この XML は iPojo XML に置き換えられると思いますか?

  4. scrinfo.xml これは、private="false"各ノードにのみ追加される serviceComponents.xml の複製です。

  5. metatype.xml これは、生成された他の XML のように見えますが、SCR 名前空間を使用していません。

  6. ライブラリ これらは、システムの残りの部分に公開されていないバンドルのプライベートな依存関係であると推測しています。

これがうねる質問であるという事実は好きではありませんが、OSGi の Apache-Felix 実装が探しているものと、一方のテクノロジーがどこで終わり、他方のテクノロジーがどこで始まるかについて、信頼できる図を見つけることができないようです。オーバーラップを示す適切な図がどこかにあれば、それは役に立ちます。または、誰かが特定の推奨スタックに絞り込んで、技術的な詳細を整理しながら目隠しをすることができれば、それは素晴らしいことです.

4

1 に答える 1

3

数バイト余分に気にする正当な理由がない限り、Maven プラグインがバンドル jar に何を入れるかについてはあまり心配しません。

あなたのリストAFAICSから、おそらくlibの下のjarファイルを除いて、すべてのファイルがそこにある正当な理由があります。これらの依存関係を埋め込むために設定されているmaven-bundle-pluginによって含まれていると思います。通常、バンドルでこれらのパッケージを他のバンドルからインポートすることをお勧めします。これにより、バンドルで使用されるだけでなく、共有できるようになります。

Apache Sling を使用している場合は、 Sling コードベースの /bundles の下にあるほぼすべてのバンドルを例として使用できます。それらは確立されたベスト プラクティスに従って構築されています。Sling コードベースは、Maven プラグインによって実行されるビルド時に内部で ServiceTrackers、ホワイトボード パターンと多くの宣言型サービス、および BND を使用します。

私自身は iPojo を使用したことがありません。Sling でうまく動作すると思いますが、Sling 自体ではその必要性は見られませんでした。

私は OSGi アプリケーションで Spring を使用するのが好きではありません。一部の人々はそれをうまく行っているようですが、IMO は追加のレイヤーであり、単純な宣言型サービスと比較してあまり価値がありません。

于 2013-11-07T19:37:14.227 に答える