我一直在思考一些关于osgi包中的包结构的“良好实践”。目前，平均而言，我们每捆有8-12个班级。我的主动/建议之一是有两个包; com.company_name.osgi.services.api（用于与api相关的类/接口（外部导出）和一个用于实现的包com.company_name.osgi.services.impl（未导出））。这有什么优点？还有其他建议吗？
答案 0 :(得分：6)
您也可以考虑将接口放在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 :(得分：2)
这不是重要的课程数量，而是概念。在我看来，你应该在一个包中有一个概念实体。在某些情况下，这可能只是其他几个包含100个类的几个类。
重要的是您将API与实现分开。一个包包含您的概念的API，另一个包含实现。像这样，您可以为定义良好的API提供不同的实现。在某些情况下，如果您想远程访问捆绑服务（例如使用R-OGSi），甚至可能需要这样做
然后，API捆绑包由代码共享和服务共享中的实现捆绑包中的服务使用。探索这些可能性的最佳方式是查看ServiceTrackers。
答案 2 :(得分：0)
在你的情况下，你可以在同一个包中实现，但是它的所有类都“包受保护”。这样，您可以导出包，并且即使不使用OSGi（但作为常规jar文件），外部也不会看到实现。