私はosgiバンドル内のパッケージ構造に関する "良い実践"について考えてきました。現在、平均してバンドルあたり8-12クラスがあります。私のイニシアチブ/提案の1つは2つのパッケージを持つことでした。 com.company_name.osgi.services.api（外部にエクスポートされるAPI関連のクラス/インタフェース用）と実装用の1つのパッケージcom.company_name.osgi.services.impl（エクスポートされない））。これの長所は何ですか？その他の提案はありますか？OSGiバンドルのパッケージ構造
また、インターフェイスをcom.company_name.subsystemに設定し、実装がcom.company_name.subsystem.impl、OSGI固有のコード（ある場合）がcom.company_name.subsystem.osgiになる可能性があります。 同じインターフェイスを複数実装していることがあります。この場合、あなたは考えることができ - com.company_name.subsystem.impl1とcom.company_name.subsystem.impl2を、例えば：この意味パッケージ構造で
com.company.scm // the scm api
com.company.scm.git // its git implementaton
com.company.scm.svn // its subversion implementation
com.company.scm.osgi // the place to put an OSGI Activator
をOSGiのとらわれない可能性があり、後で別のコンテナに移動して、あなただけの追加
com.company.scm.sca // or whatever component model you might think of
パッケージ名に常にapiとimplがあると迷惑になることがあります。疑わしい場合はimplを使用しますが、apiは使用しないでください。
これは重要なクラスの数ではなく、概念です。私の意見では、1つの概念エンティティをバンドルに入れる必要があります。場合によっては、100sのクラスを持つ他のいくつかのパッケージのほんの少数のクラスかもしれません。
重要な点は、APIと実装を分離することです。 1つのバンドルにはコンセプトのAPIがあり、もう1つの実装には実装が含まれています。このように、明確に定義されたAPIに対してさまざまな実装を提供することができます。場合によっては、バンドルからサービスをリモートで（例えばR-OGSiを使用して）アクセスする場合にも必要な場合があります。
APIバンドルはサービス共有によって実装バンドルのコード共有とサービスによって使用されます。これらの可能性を探る最良の方法は、ServiceTrackersを見ることです。
あなたの場合は、同じパッケージに実装されていても、すべてのクラスがパッケージ保護されている可能性があります。この方法では、パッケージをエクスポートすることができ、OSGiを使用していないとき（ただし、通常のjarファイルとして）でも、実装は外部には見えません。