What it doesThe Java Simple Plugin Framework was built to reduce development time while increasing code maintainability of small to medium sized projects.
Completely hides implementation details of components. Only use their interfaces. Components may be loaded with only two(!) lines of code
... [More]
Heavily annotation based: @PluginImplementation, @InjectPlugin, @PluginLoaded, @Timer and @Thread, ... Through usage of generics it is usually type safe. Additional plugins to export other plugins by JavaScript, JSON, LipeRMI, XMLRPC, XMLRPC Delight or ERMI. Plugins may be discovered on the local net using ZeroConf. Initial support for RDF. Only 156k core size. (See the Usage Guide, FAQ or Introduction-Video for more information).
What is new in this version (0.8.0, January 2010)Meta handling introduced. You can now intercept calls to plugins and alter parameters or the return value. This works by using 1) the PluginSupervisor and 2) by setting "supervision.enabled" to "true". Added warnings if plugins start too slowly. This should give you an indicator where to start optimizing for startup performance. ClassURI added. Allows for really fast startups in the case you need them. logging.level is now a property of PluginManager.class, simplifies debugging a bit. Pluglets (Just for testing, may be removed again in the future) discover://youngest, discover://oldest. Now you can actually discover the most recent / longest running version of a network service. @InjectPlugin now also works on methods (just make the method accept a plugin of some type) Added Scala support (see the Usage Guide for details) Significantly improved the speed of the cache. (Makes the startup even faster) Switched to Java 1.6. (And again some speedups) Introduced simple function caching (Preliminary...) Tons of bugs and deadlocks fixed.
A short exampleThe following lines demonstrate how easy it is to load existing plugins. All .JAR files inside the given directory will be examined for contained plugins which will be loaded afterwards and are automatically started. No configuration files are required, nothing else has to be done.
PluginManager pm = PluginManagerFactory.createPluginManager();
// and then one or more of these ...
pm.addPluginsFrom(new File("myPluginDir/").toURI());
pm.addPluginsFrom(new File("myPluginDir/myPlugin.jar").toURI());
pm.addPluginsFrom(new URI("classpath://*"));
pm.addPluginsFrom(new URI("http://server.com/plugin.jar"));
pm.addPluginsFrom(new ClassURI(RemoteDiscoveryImpl.class).toURI());
Creating a new plugin is equally straightforward. After an interface has been designed the rest can be done by a simple annotation. The next example shows a plugin implementation that could be loaded by JSPF, and also here: no XML- or whatsoever-files have to be created to make this work.
/**
* CoolPlugin may be an (almost) arbitrary interface, in only has to extend Plugin.
*/
@PluginImplementation
public class CoolPluginImpl implements CoolPlugin {
public String provideData() {
return "Hello World";
}
}Our last two snippes indicates how plugins can be obtained from outside, and the inside of plugins. Notice the type-safety:
CoolPlugin cool = pm.getPlugin(CoolPlugin.class);Or, from inside of plugins:
@InjectPlugin
public CoolPlugin cool;
When to use itIf you
are, for example, a researcher and want to develop a prototype quickly intend to change implementations frequently but want to keep your code clean are coding some software where you expect plugins to be loaded using some kind of easy IoC think about reusing components in other prototypes then you might want to give it a try.
Functionality Checklist(aka the unbiased JSPF-is-great feature matrix)
Below you find a brief overview of the most important features JSPF has to offer. This list is not complete, and the framework offers various other goodies here and there, like flexible options, easy configuration support and some more.
Feature JSPF Can load ... plugins from JAR files Yes ... multiple plugins from path Yes ... automatically all plugins in classpath Yes ... plugins over HTTP Yes (1) Threadsafe Yes Typesafe Yes Dependency Injection Yes Simple, XML free configuration Yes Heavily annotation based Yes Supports caching Yes Plugins can be isolated using a separate ClassLoader Yes (2) Official support to export plugins over ... ERMI Yes ... LipeRMI Yes (3) ... JSON (easily export Plugins to web pages!) Yes ... XMLRPC Yes Transparent and easy network callbacks Yes (w. LipeRMI) Remote plugins may be discovered automatically Yes Requires Java version >=6.0 Supported Platforms Windows, Mac, Linux Works in applets Yes (4) Core size 156k (5) Time to get started 5 minutes (6) License Free (beer and speech) Proper end user documentation :-(
(1) Works, but unsafe and not recommended.
(2) Only if the plugins are packed into a self contained JAR.
(3) We even use a greatly enhanced version of LipeRMI with fewer bugs and more featues.
(4) Applets have to be signed, does not work with classpath autodetection
(5) Likely to increase with every new version, remote plugins add extra size
(6) If you watch the introduction video and have profound Java experience.
Known UsersGerman Research Center for Artificial Intelligence (various projects) Text 2.0 Project (official website)
Help & FeedbackWe know the documentation is in a bad shape. However, in case you have any questions, comments or requests, don't hesitate to visit my web page and drop me a mail. I will add the items to the wiki afterwards.
HistoryThis project was created by Ralf Biedert. Nicolas Delsaux started the hosting on code.google.com and added some features. Thomas Lottermann contributed to various plugins. [Less]
Copyright
©
2013
Black Duck Software, Inc.
and its contributors, Some Rights Reserved. Unless otherwise marked, this work is licensed under a
Creative Commons Attribution 3.0 Unported License
. Ohloh
®
and the Ohloh logo are trademarks of
Black Duck Software, Inc.
in the United States and/or other jurisdictions. All other trademarks are the property of their respective holders.