用 Java 构建插件系统的最佳方式
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/465099/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Best way to build a Plugin system with Java
提问by Sven Lilienthal
How would you implement a Plugin-system for your Java application?
您将如何为您的 Java 应用程序实现插件系统？
Is it possible to have an easy to use (for the developer) system which achieves the following:
是否有可能有一个易于使用（对于开发人员）的系统来实现以下目标：
- Users put their plugins into a subdirectory of the app
- The Plugin can provide a configuration screen
- If you use a framework, is the license compatible with commercial developement?
- 用户将他们的插件放入应用程序的子目录中
- 该插件可以提供一个配置屏幕
- 如果使用框架，许可证是否与商业开发兼容？
采纳答案by Bombe
First you need an interface that all plugins need to implement, e.g.
首先你需要一个所有插件都需要实现的接口，例如
public interface Plugin {
public void load(PluginConfiguration pluginConfiguration);
public void run();
public void unload();
public JComponent getConfigurationPage();
}
Plugin authors should then bundle their plugins into JAR files. Your applications opens the JAR file and could then use an attribute from JAR manifest or the list of all files in the JAR file to find the class that implements your Plugin interface. Instantiate that class, the plugin is ready to go.
然后插件作者应该将他们的插件捆绑到 JAR 文件中。您的应用程序打开 JAR 文件，然后可以使用 JAR 清单中的属性或 JAR 文件中所有文件的列表来查找实现插件接口的类。实例化那个类，插件就可以使用了。
Of course you may also want to implement some kind of sandboxing so that the plugin is restricted in what it can and can not do. I have created a small test application(and blogged about it) that consists of two plugins, one of which is denied access to local resources.
当然，您可能还想实现某种沙箱，以便限制插件可以做什么和不能做什么。我创建了一个包含两个插件的小型测试应用程序（并在博客上发表了相关文章），其中一个插件被拒绝访问本地资源。
回答by Aaron Maenpaa
Use OSGi.
使用OSGi。
It is the foundation of the Eclipse plug-in system. Equinoxis Eclipse's implementation (licensed EPL) and Felixis the Apache Project's implementation (licensed Apache Public License).
它是 Eclipse 插件系统的基础。Equinox是 Eclipse 的实现（获得许可的 EPL），而Felix是 Apache 项目的实现（获得许可的 Apache Public License）。
Eclipse provides a concrete example that OSGi can cover the points you mentioned (or you could just build your application on top of Eclipse RCPif you want a full Eclipse/SWT/JFace stack).
Eclipse 提供了一个具体示例，OSGi 可以涵盖您提到的要点（或者，如果您想要完整的 Eclipse/SWT/JFace 堆栈，您可以在Eclipse RCP之上构建您的应用程序）。
回答by jan
There is also JPF (Java Plugin Framework).
回答by Pete Kirkham
Since 1.6, there's been java.util.ServiceLoaderwhich can be used if you want to code your own simple system.
从 1.6 开始，如果您想编写自己的简单系统，就可以使用java.util.ServiceLoader。
But if you want anything more than basic features, use one of the existing frameworks.
但是，如果您想要的不仅仅是基本功能，请使用现有框架之一。
回答by Steen
I think that recommending OSGi for solving the above stated problem is extremely poor advice. OSGi is "the right choice" but for a scenario as the one above, I think either JPF or some homegrown minimalistic framework is sufficient.
我认为推荐 OSGi 来解决上述问题是非常糟糕的建议。OSGi 是“正确的选择”，但对于上述场景，我认为 JPF 或一些本土的简约框架就足够了。
回答by adrian.tarau
Years ago I started a project like that and I hope soon will be ready.I got inspired by projects like NetBeans and Eclipse but meanwhile it changed to something a little bit different. OSGi looks like a good choice now, but I didn't had a chance to compare it with my project.It is similar with JPF mentioned above, but in the same time different in many ways.
几年前，我开始了一个这样的项目，我希望很快就会准备好。我从 NetBeans 和 Eclipse 等项目中得到了启发，但与此同时，它变成了一些不同的东西。OSGi现在看起来是个不错的选择，但是我没有机会和我的项目进行比较。它与上面提到的JPF相似，但同时在许多方面有所不同。
The basic idea which motivated me is to be as easy as possible to build Java application, with no separation between web applications, desktop applications or applet/JWS applications(of course this doesn't cover the UI - yet) as a core functionality.
激励我的基本思想是尽可能简单地构建 Java 应用程序，在作为核心功能的 Web 应用程序、桌面应用程序或小程序/JWS 应用程序（当然这不包括 UI - 尚未）之间没有分离。
I built the project with a few goals in my mind :
我在脑海中建立了几个目标：
- it doesn't matter if you build a web application or a desktop application you should start the application in the same way, a plain main method, No fancy web.xml declaration(not that I'm against having a standard web descriptor, but it doesn't go well with a plug-in system, where you add "servlets" - I call them RequestHandler(s) - dynamic at your will).
- easy to plug in "extensions" around an "extension point" - something from Eclipse but a different approach.
- self-deployable, since all the plugins are registered(XML files) the application must be self-deployable independent of the build system - of course there is an Ant task and a Maven MOJO which are the links with the ourside world, but in the end it calls the application and instruct it to self-deploy itself at a specific location.
- borrowed from Maven, it can download code from repositories(including Maven 1 & 2 repositories) so your application can be deployed as a single small jar as long as you have access to the repositories(useful sometime, and basically this provides support for auto-updates - don't you love the idea to be notified by your web application that there is a newer version, it was downloaded and it just needs your permission to install it? I know I love that).
- basic application monitoring about system health, email notifications in case of failures
- 无论您构建 Web 应用程序还是桌面应用程序，都应该以相同的方式启动应用程序，一个普通的 main 方法，没有花哨的 web.xml 声明（并不是说我反对使用标准的 Web 描述符，但是它不适用于插件系统，您可以在其中添加“servlet”——我称它们为 RequestHandler(s)——随意动态）。
- 很容易在“扩展点”周围插入“扩展” - 来自 Eclipse 但不同的方法。
- 可自我部署，因为所有插件都已注册（XML 文件），因此应用程序必须独立于构建系统进行自我部署 - 当然有一个 Ant 任务和一个 Maven MOJO，它们是与我们的世界的链接，但在最后它调用应用程序并指示它在特定位置自我部署。
- 从 Maven 借来的，它可以从存储库（包括 Maven 1 和 2 存储库）下载代码，因此只要您有权访问存储库，您的应用程序就可以部署为单个小 jar（有时很有用，基本上这提供了对自动-更新 - 您不喜欢 Web 应用程序通知您有更新版本的想法，它已被下载并且只需要您的许可才能安装它？我知道我喜欢那个）。
- 关于系统健康状况的基本应用程序监控，出现故障时的电子邮件通知
回答by Sean Anderson
I worked on OSGi for a week--an intense, nothing but OSGi week. At the end it was like a bad dream but I learned a lot.
我在 OSGi 上工作了一周——这是一个紧张的一周，除了 OSGi 什么都没有。最后就像一场噩梦，但我学到了很多。
I was able to get OSGi working (not easy, all examples are out of date, everything on the net is at least three years old if not five), but I had serious trouble getting it integrated into an existing project because of issues with the jar manifests.
我能够让 OSGi 工作（不容易，所有例子都过时了，网络上的所有东西如果不是五年的话，至少已经三年了），但是由于存在问题，我很难将它集成到现有项目中罐子清单。
In short, there are only a few obscure tools used for building manifests and they are not well documented (BND Tools is hardly obscure, but it is designed for a certain process in Eclipse). Also, most of the OSGi information available is not targeted towards application developers who have an existing desktop application.
简而言之，用于构建清单的工具很少，而且没有很好的文档记录（BND 工具并不晦涩，但它是为 Eclipse 中的某个过程而设计的）。此外，大多数可用的 OSGi 信息并不针对拥有现有桌面应用程序的应用程序开发人员。
This makes a lot of the context for the information foggy or inappropriate. Neil Bartlett's blog posts were the biggest help, but even those failed to get a working system (I grabbed some code from the Felix tutorial and pieced it together to get the embedded framework rolling). I found his book draft that he posted for free years ago, which is excellent, but the examples in Eclipse do not work because of changes in Eclipse OSGi support.
这使得信息的许多上下文模糊或不合适。Neil Bartlett 的博客文章是最大的帮助，但即使是那些也未能获得一个工作系统（我从 Felix 教程中获取了一些代码并将其拼凑起来以启动嵌入式框架）。我发现他几年前免费发布了他的书稿，这很好，但是由于 Eclipse OSGi 支持的变化，Eclipse 中的示例不起作用。
Every step is a major hurdle. I will try to post some more details here later.
每一步都是一个重大障碍。稍后我将尝试在此处发布更多详细信息。
