java internal_java – 控制对“.internal”包的访问的最佳实践

不是仅仅是将Meta-INF / MANIFEST.MF更新为一个插件osgi项目(如果还没有？).它应该看起来像：

Manifest-Version: 1.0

Bundle-ManifestVersion: 2

Bundle-Name: My-plugin

Bundle-SymbolicName: com.mycompany.mypluginname

Bundle-Version: 1.0.0

Bundle-Vendor: MyCompany

Bundle-requiredExecutionEnvironment: JavaSE-1.6

Service-Component:

Import-Package: org.apache.log4j;version="1.2.14" (,separated etc)

Export-Package: com.mycompany.mypluginname.myapipackage;version="1.0.0"

然后很好地省略了.内部包.平台应该休息.

顺便说一下,然后使用Import-Package：在任何依赖的bundle,plugins等中,而不是依赖于jar / project(这是老的,吮吸的方式,它不起作用 – 正如你所发现的).

这样可以大大减少你的代码依赖关系.如果你决定你的插件代码应该属于不同的jar / bundle,那么你只需移动单独的包,并使新的bundle / plug-in导出它.由于客户端捆绑从“云”导入包(云作为OSGi平台),您可以更自由地移动代码.

注意：如评论中所述,您不需要在OSGi中运行应用程序来获得此“受益”. Eclipse可以在OSGi包限制下编译它的代码,并且您的构建/服务器可以在“未受保护的世界”中运行.例如OSGi清单不对第三方(希望使用内部)执行任何操作,但对那些想要它们的人提供“通知”和限制.