控制对“.internal”访问的最佳实践。包 [英] Best practice for controlling access to a ".internal" package

问题描述

我编写Eclipse插件并将一些类导出为API，同时希望限制对其他类的访问。

I write Eclipse plugins and export some classes as an API while wanting to restrict access to other classes.

我按照Eclipse的常规做法将这些类分成.internal子包。

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 / project（这是旧的，sucky）无法正常工作的方式 - 正如您所发现的那样。）

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清单不对第三方（希望使用.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.

这篇关于控制对“.internal”访问的最佳实践。包的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！