javacなどのツールを使用してソースからバンドルを作成するには、線形クラスパスを提供する必要があります。残念ながら、OSGiの観点からはまだ完全に合法である状況では機能しません。
JARが埋め込まれた依存関係。
異なる依存関係に含まれる同じパッケージ。
javacはOSGiメタデータを理解しないので、単純に理解することはできませんが、クラスパスの依存関係を理解することができます。より細かいパッケージのきめ細かいアプローチが必要と思われます。
自動化されたプロセス（継続的インテグレーション）でOSGiを使用している人々は、この問題にどのように対処しますか？不思議なことに、バンドルJARの作成方法（メタデータの作成、JARの作成）については、クラス/内部JARを内部に配置する方法について多くのリソースがありますが、実際にこれらのクラスをコンパイルする方法についてはほとんどありません。
例を見てみましょう。私のバンドルをコンパイルするには、他に2つのバンドルが必要です。どちらにもXercesが埋め込まれたJARとして含まれていますが、2つの異なる互換性のないバージョンがあります。そのうちの1つだけが、私のバンドルがインポートしているxercesのいくつかのパッケージをエクスポートするので、問題はありません。あまりクリーンな状況ではないかもしれませんが、OSGiコンテナで問題なく「合法的に」発生する可能性のある問題が発生します。
さて、どうすればコンパイルできますか？2つの依存関係をクラスパスに入れることができません（埋め込まれたXerces JARはjavacで見つかりません）、フラット化することもできません（2つのバージョンのXercesが衝突し、エクスポートされていないバージョンが最初になる可能性があります） 。唯一の解決策が、フルバンドルスケールではなくパッケージレベルで「クラスパス」を作成することである場合、javacはまったく使用できません。