We will discuss the implementation of the QuickNotepad plugin, along with the jEdit APIs it makes use of. But first, we describe how plugins are loaded.
As part of its startup routine, jEdit's main method calls various methods to load and initialize plugins.
Plugin loading occurs after jEdit has loaded application properties, any user-supplied properties, and the application's set of actions that will be available from jEdit's menu bar (as well as the toolbar and keyboard shortcuts).
Plugin loading occurs before jEdit opens the initial view or loads any files for editing. It also occurs before jEdit runs any startup scripts.
Plugins are loaded from files with the .jar filename extension located in the jars subdirectories of the jEdit installation and user settings directories (see Section , “The jEdit Settings Directory”).
For each JAR archive file it finds, jEdit scans its entries and performs the following tasks:
Adds to a collection maintained by jEdit a new object of type EditPlugin.JAR. This is a data structure holding the name of the JAR archive file, a reference to the JARClassLoader, and a collection of plugins found in the archive file.
Loads any properties defined in files ending with the extension .props that are contained in the archive. See Section , “The Property File”.
Reads action definitions from any file named actions.xml in the archive (the file need not be at the top level). See Section , “The Action Catalog”.
Parses and loads the contents of any file named dockables.xml in the archive (the file need not be at the top level). This file contains BeanShell code for creating docking or floating windows that will contain the visible components of the plugin. Not all plugins define dockable windows, but those that do need a dockables.xml file. See Section , “The Dockable Window Catalog”.
Checks for a class name with a name ending with Plugin.class.
Such a class is known as a plugin core class and must extend jEdit's abstract EditPlugin class. The initialization routine checks the plugin's properties to see if it is subject to any dependencies. For example, a plugin may require that the version of the Java runtime environment or of jEdit itself be equal to or above some threshold version. A plugin can also require the presence of another plugin.
If any dependency is not satisfied, the loader marks the plugin as “broken” and logs an error message.
After scanning the plugin JAR file and loading any resources, a new instance of the plugin core class is created and added to the collection maintained by the appropriate EditPlugin.JAR. jEdit then calls the start() method of the plugin core class. The start() method can perform initialization of the object's data members. Because this method is defined as an empty “no-op” in the EditPlugin abstract class, a plugin need not provide an implementation if no unique initialization is required.