Theseus Generic Plugin Engine

Overview

The Theseus Generic Plugin Engine is a container that manages dynamically loadable chunks of code, called plugins. Other pluggable architectures may refer to these as modules, fragments, add-ons and so forth. Regardless, the idea is that they allow a bit of code not known at compile time to be added to an application in some manner, dynamically, to extend, add to or otherwise provide more functionality that was originally unavailable at the time the application was compiled. You'll often see applications like Photoshop, 3D Studio, LightWave, and even developer tools like JEdit, Eclipse and JBuilder, provide "hooks", or API's that allow developers not associated with the core product to extend the product in some way that suits their needs.

The Theseus Generic Plugin Engine strives to provide a very flexible, powerful, yet easy to develop for container for the easy addition of dynamically loaded plugins. It is not tied to a specific area of Java, such as Swing, or J2EE. Instead, it is built upon the foundation that it can be added to any application with a few lines of code, giving that application an easy path to extensibility beyond it's original intentions... if you will, it can bring new life to old applications in ways never imagined. But don't think that it's only usage is for existing applications. A special Swing based UI framework (click here for more) is being built from the ground up completely based around the plugin engine. This framework will consist of a simple launcher class and the rest are all plugins.

The plugin engine has a few concepts that need to be understood to really take full advantage of its capabilities. Thankfully, they are not many and are easy to start working with. The engine comes with some example applications that make use of it and many plugins to help teach how to use the engine and build plugins. This html documentation should provide additional technical and informative help, and lastly the mail list, found at sourceforge can be of great help, where the developers of the engine often discuss development issues, bug fixes, and so forth, as well as ideas, and help others with using the engine.

While the underlying plugin engine is less than 100K in size, including an xml read/write pull parser embeded, it is by no means tiny in features. The engine sports a number of advanced capabilities. Besides being able to specify any number of directories to scan for plugins, plugins have two formats they may use. One, particularly useful for development, is the exploded directory format. In this form, a directory resides on disk and the plugin compiled classes, any libraries it depends on, and the plugin.xml descriptor all reside below the directory. The other format is the plugin archive file, a self contained representation of the exploded dir format, but contained in a single deployable file. This leads in to another feature. Most, if not all present pluggable architectures employ either a single .zip or .jar file, which then has to be unzipped/jarred to disk somewhere, or they usually provide an exploded directory structure as explained above. When you download plugins, either an installer, our you will manually unzip/unjar/install the plugin to a given directory. The Theseus Generic Plugin Engine goes a step further in providing the ability to directly read and create class files, as well as other resources like html and text files, images, icons and so forth, from the plugin archive file without the need to unzip it to a directory. Unlike the jar format, which can not contain dependent embeded libraries (at least not without them having to be unjarred from the archive to disk to be used), the plugin archive file format will make full use of embeded zip and jar libraries at runtime without having to unzip them from the archive to disk. What's more, the engine allows each application to specify the file extension names that plugins can use. The default is .PAR for Plugin ARchive. But you can make it anything. This may be particularly useful if you want to "mask" core plugins from 3rd party plugins, so that end users may not realize a file is actually a plugin, at least not without snooping around files and guessing they might be.