public interface Plugin {
public void load(PluginConfiguration pluginConfiguration);
public void run();
public void unload();
public JComponent getConfigurationPage();
}
插件作者应该将他们的插件捆绑到 JAR 文件中。 您的应用程序打开 JAR 文件，然后可以使用 JAR 清单中的属性或 JAR 文件中所有文件的列表来查找实现您的插件接口的类。 实例化该类，插件就可以使用了。
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.
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.
It is the foundation of the Eclipse plug-in system. Equinox is Eclipse's implementation (licensed EPL) and Felix is the Apache Project's implementation (licensed 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 RCP if you want a full Eclipse/SWT/JFace stack).
这使得很多信息的上下文变得模糊或不恰当。 Neil Bartlett 的博客文章提供了最大的帮助，但即使这些文章也未能获得一个可运行的系统（我从 Felix 教程中获取了一些代码并将其拼凑在一起以使嵌入式框架滚动）。 我找到了他几年前免费发布的书稿，非常棒，但是由于 Eclipse OSGi 支持的变化，Eclipse 中的示例不起作用。
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.
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.
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.
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.
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.
激励我的基本想法是尽可能简单地构建 Java 应用程序，并且不区分 Web 应用程序、桌面应用程序或 applet/JWS 应用程序（当然这还不包括 UI）作为核心功能。
我构建这个项目时心里有几个目标：
无论你构建一个 Web 应用程序还是桌面应用程序，你都应该以相同的方式启动应用程序，一个简单的 main 方法，没有花哨的 web.xml 声明（不是我反对使用标准的 Web 描述符，但它与插件系统不太兼容，在插件系统中您添加“servlet” - 我称它们为 RequestHandler（s） - 随您的意愿动态）。
很容易在“扩展点”周围插入“扩展”——来自 Eclipse 的东西，但方法不同。
可自行部署，因为所有插件都已注册（XML 文件），所以应用程序必须独立于构建系统而可自行部署 - 当然，有一个 Ant 任务和一个 Maven MOJO，它们是与我们外部世界的链接，但在最后它调用应用程序并指示它在特定位置自行部署。
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.
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.
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
发布评论
评论（8）
首先，您需要一个所有插件都需要实现的接口，例如
插件作者应该将他们的插件捆绑到 JAR 文件中。 您的应用程序打开 JAR 文件，然后可以使用 JAR 清单中的属性或 JAR 文件中所有文件的列表来查找实现您的插件接口的类。 实例化该类，插件就可以使用了。
当然，您可能还想实现某种沙箱，以便限制插件可以做什么和不能做什么。 我创建了一个小型 测试应用程序 （和 关于它的博客）由两个插件组成，其中一个插件被拒绝访问本地资源。
First you need an interface that all plugins need to implement, e.g.
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.
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.
使用OSGi。
它是Eclipse插件系统的基础。 Equinox 是 Eclipse 的实现（已获得 EPL 许可），Felix 是 Apache 项目的实现（获得 Apache 公共许可证）。
Eclipse 提供了一个具体的示例，OSGi 可以涵盖您提到的要点（或者您可以在 Eclipse RCP（如果您想要完整的 Eclipse/SWT/JFace 堆栈）。
Use OSGi.
It is the foundation of the Eclipse plug-in system. Equinox is Eclipse's implementation (licensed EPL) and Felix is the Apache Project's implementation (licensed 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 RCP if you want a full Eclipse/SWT/JFace stack).
从 1.6 开始，出现了 java.util.ServiceLoader 如果您想编写自己的简单系统，可以使用它。
但如果您想要的不仅仅是基本功能，请使用现有框架之一。
Since 1.6, there's been java.util.ServiceLoader which can be used if you want to code your own simple system.
But if you want anything more than basic features, use one of the existing frameworks.
使用 PF4J。
它支持 Web、Spring 和 Wicket。
易于使用和构建应用程序
Use PF4J.
It has support for Web, Spring and Wicket.
Easy to use and build the applications
还有JPF（Java 插件框架）。
There is also JPF (Java Plugin Framework).
我在 OSGi 上工作了一周——紧张、除了 OSGi 之外什么也没有的一周。 最后，这就像一场噩梦，但我学到了很多。
我能够让 OSGi 工作（并不容易，所有示例都已过时，网络上的所有内容至少有三年历史（如果不是五年）），但由于存在问题，我在将其集成到现有项目中时遇到了严重困难jar 显现。
简而言之，用于构建清单的工具很少，而且没有很好的文档记录（BND Tools 并不晦涩，但它是为 Eclipse 中的某个过程而设计的）。 此外，大多数可用的 OSGi 信息并不针对拥有现有桌面应用程序的应用程序开发人员。
这使得很多信息的上下文变得模糊或不恰当。 Neil Bartlett 的博客文章提供了最大的帮助，但即使这些文章也未能获得一个可运行的系统（我从 Felix 教程中获取了一些代码并将其拼凑在一起以使嵌入式框架滚动）。 我找到了他几年前免费发布的书稿，非常棒，但是由于 Eclipse OSGi 支持的变化，Eclipse 中的示例不起作用。
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.
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.
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.
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.
我认为推荐 OSGi 来解决上述问题是非常糟糕的建议。 OSGi 是“正确的选择”，但对于上述场景，我认为 JPF 或一些本土的简约框架就足够了。
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.
几年前，我开始了一个类似的项目，我希望很快就能准备好。我受到 NetBeans 和 Eclipse 等项目的启发，但同时它发生了一些变化。 OSGi 现在看起来是一个不错的选择，但我没有机会将它与我的项目进行比较。它与上面提到的 JPF 类似，但同时在很多方面有所不同。
激励我的基本想法是尽可能简单地构建 Java 应用程序，并且不区分 Web 应用程序、桌面应用程序或 applet/JWS 应用程序（当然这还不包括 UI）作为核心功能。
我构建这个项目时心里有几个目标：
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.
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.
I built the project with a few goals in my mind :