控制对“.internal"访问的最佳实践包裹
我编写 Eclipse 插件并将一些类导出为 API，同时希望限制对其他类的访问.
I write Eclipse plugins and export some classes as an API while wanting to restrict access to other classes.
我遵循将这些类分成.internal"子包的常见 Eclipse 做法.
I follow the common Eclipse practice of separating these classes into a ".internal" subpackage.
但是，我不能对这些类使用包"或默认级别访问权限，因为其中许多需要由我正在导出的类使用.
However, then I can't use "package" or default level access on these classes since many of them need to be used by the classes I'm exporting.
防止或劝阻我的 API 用户将这些类用于他们自己的目的的最佳做法是什么?有自动检查器吗?
What is the best practice for preventing or discouraging users of my API from using these classes for their own purposes? Is there an automatic checker?
我承认，当我别无选择时，我曾涉足过使用 Eclipse 的一些内部类 :)
I admit that I've dabbled in using some of Eclipse's internal classes when I had no choice :)
澄清:我对非插件代码也有类似的需求.
Clarification: I have a similar need with non-plugin code.
推荐答案
不就是将 META-INF/MANIFEST.MF 更新为一个插件 osgi 项目(如果还没有的话?).它应该类似于:
Isn't it just a case of updating the META-INF/MANIFEST.MF to being a plug-in osgi project (if it's not already?). It should look something like:
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"
然后很好地省略 .internal 包.平台应该完成其余的工作.
And then nicely omit the .internal package. The platform should do the rest.
顺便说一句，然后您可以在任何依赖的捆绑包、插件等中使用 Import-Package:，而不是依赖于 jar/项目(这是旧的、糟糕的方式，它不起作用 - 正如您所发现的那样).
By the way, you then use the Import-Package: in any dependent bundles, plugins etc, rather than depending on the jar/project (which is the old, sucky way which doesn't work - as you're finding).
这使您可以大量解耦代码依赖项.如果你决定你的插件代码应该属于不同的 jar/bundle，你只需移动单个包，然后让新的 bundle/plug-in 导出它.由于客户端包只是从云"(云是 OSGi 平台)导入包，因此您可以更自由地移动代码.
This gives you massive de-coupling of your code dependencies. If you decide that your plugin code should belong in a different jar/bundle, you just move individual packages, and make the new bundle/plug-in export it. Since the client bundles just import the package from "the cloud" (cloud being the OSGi platform), you can move code a lot more freely.
注意:如评论中所述，您无需在 OSGi 中运行您的应用程序即可获得此好处".Eclipse 可以在 OSGi 包限制下编译它的代码，并且您的构建/服务器可以在不受保护的世界"中运行.例如OSGi 清单不会对第 3 方(希望使用 .internal)强制执行任何操作，但会向需要它们的人提供通知"和限制.
Note: As mentioned in the comments, you don't need to be running your apps in OSGi to get this "benefit". Eclipse can compile it's code under OSGi package restrictions, and your build/server can run in "the unprotected world". e.g. the OSGi manifests don't enforce anything to 3rd parties (who wish to use .internal), but provide "notifications" and restrictions to those that want them.
相关文章