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

這不是重要的課程數量，而是概念。 在我看來，你應該在一個包中有一個概念實體。 在某些情況下，這可能只是其他幾個包含100個類的幾個類。

重要的是您將API和實現分開。 一個包包含您的概念的API，另一個包含實現。 像這樣，您可以為定義良好的API提供不同的實現。 在某些情況下，如果您想遠程訪問捆綁服務（例如使用R-OGSi），甚至可能需要這樣做

然后，通過服務共享，代碼共享和來自實現包的服務使用API​​包。 探索這些可能性的最佳方式是查看ServiceTrackers。

Answer 3

在您的情況下，您可以在同一個包中實現，但它的所有類都“包受保護”。 這樣，您可以導出包，並且即使不使用OSGi（但作為常規jar文件），外部也不會看到實現。