OSGi 包的包结构

Question

我一直在思考有关 osgi 捆绑包内的包结构的“良好实践”。目前，平均每个包有 8-12 个类。我的倡议/建议之一是有两个套餐；com.company_name.osgi.services.api（用于api相关的类/接口（向外导出）和一个用于实现的包com.company_name.osgi.services.impl（不导出））。这样做有什么优点和缺点？还有其他建议吗？

Answer 1

您可能还考虑将接口放入 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.

Answer 2

重要的不是类的数量，而是概念。在我看来，你应该在一个捆绑包中拥有一个概念实体。在某些情况下，这可能只是其他几个包含数百个类的包中的几个类。

重要的是要将 API 和实现分开。一个包包含您的概念的 API，另一个包包含实现。像这样，您可以为定义良好的 API 提供不同的实现。在某些情况下，如果您想远程访问捆绑包中的服务（例如使用R-OGSi)

然后，代码共享使用 API 包，服务共享使用实现包中的服务。探索这些可能性的最佳方法是查看 ServiceTrackers。

Answer 3

在您的情况下，您可以将实现在同一软件包中，但其所有类都“受保护”。这样，您可以导出软件包，即使不使用OSGI（而是作为常规JAR文件），外部也看不到外部。