KNIME is built upon Eclipse, employing its wealth of functionality in a variety of ways. A key concept behind Eclipse is its use of plugins which can be added onto an existing installation to provide additional functionality. The existing installation does not need to know about these extension plugins beforehand, it just has to offer a so-called extension point where other plugins can register themselves and offer additional functionality. At Eclipse's base/core, there is just a small runtime engine that executes plugins and determines their dependencies. The required structure of an Eclipse plugin includes a
plugin.xml file, which defines any dependencies to other plugins and the extension points to which the plugin wants to connect. Furthermore, a plugin can provide its own extension points to which future plugins can be connected.
The KNIME workbench takes advantage of this plugin architecture by connecting to several extension points of the Eclipse workbench (e.g. the editor-, preferences page-, perspective-extension point, etc.) KNIME itself provides two extension points to which external providers can contribute to the functionality of KNIME. These extension points are the "Categories" extension point (
org.knime.workbench.repository.categories) and the "Nodes" extension point (
org.knime.workbench.repository.nodes). The "Categories" extension point allows you to introduce new category folders displayed in the node repository (accomplished by simply adding an entry to the
plugin.xml file.) The "Nodes" extension point enables you to contribute a new functional node to the node repository (accomplished by registering the corresponding NodeFactory in the
plugin.xml file, an Eclipse plugin may provide a so-called Bundle Activator, which inherits from the Eclipse class "Plugin". This is a class which is instantiated once when a plugin is initialized and can be convenient if a plugin wishes to perform some house-keeping (e.g. check for licenses, locate external binaries, etc.) The "Bundle Activator" is registered in the obligatory
MANIFEST.MF file located in the
META-INF directory. Furthermore, the
MANIFEST.MF file contains information about the class path, required plugins, the vendor, which java packages should be made visible to other plugins, etc.
The final configuration file required for defining a plugin is the
build.properties file. It configures the way a plugin is exported. It defines the name of the jar file in which the classes of the plugin should be stored as well as all other supporting files to be included in deployment; it also enables you to define two build settings for a build package that includes the source code and for one that does not. A source folder (commonly
src) is also provided that lists any java sources of the corresponding plugin to be included in the build package.
Thankfully, all this infrastructure (especially the aforementioned files) is automatically created by the extension wizard described later in this document to enable a developer to immediately focus on writing new code and not worry about the Eclipse infrastructure.