Plug-in Support in Protégé 2.1

The use and loading of plug-ins has been revised in the Protégé 2.1 release. These changes are intended to: It is now possible for a plug-in to have documentation that is available to the user from within Protégé in the same way that standard Protégé documentation is available. A plug-in can also specify "About Box" information. Both the documentation and the About Box information are provided as HTML files.

Plug-ins are now loaded by separate class loaders. This handles a common problem that has arisen wherein plug-ins require incompatible versions of the same library. It has not previously been possible to load two such plug-ins at the same time.

What is the Change?

Before release 2.1, all plug-ins were placed in the same directory. For example, in releases 2.0 and earlier, the directory structure looked like:

	Protege_2.0/
		plugins/
			standard_extensions.jar
			jgo.jar
			jgolayout.jar
			rdf-api.jar
			rdf_backend.jar
			xerces.jar
			owl.jar
			jena.jar
			xerces.jar
			...

Now each plug-in gets it own subdirectory of the plugins directory. Thus, for Protégé 2.1 and beyond, the directory structure looks like:

	Protege_2.1/
		plugins/
			edu.stanford.smi.protegex.rdf/
				plugin.properties
				about_rdf_backend.html
				rdf-api.jar
				rdf_backend.jar
				xerces.jar
				readme
			edu.stanford.smi.protegex.owl/
				plugin.properties
				about.html
				doc/
					doc.html
					doc_page_1.html
					doc_page_2.html		
				owl.jar
				jena.jar
				xerces.jar
				...			
			edu.stanford.smi.protegex.standard_extensions/
				plugin.properties
				doc/
					graph widget/
						index.html
					table widget/
						index.html		
				standard_extensions.jar
				JGo.jar
				JGoLayout.jar
				readme

Included in each subdirectory is a file called "plugin.properties". This file specifies the names of one or more "About Box" entry HTML files and one or more documentation HTML files.
 

What about Backwards Compatibility?

For backwards compatibility purposes, we will continue to load JAR files directly from the plugins directory for some time. Users are strongly encouraged though to convert over to the 2.1 scheme as soon as possible. We do not support About Box or documentation for plug-ins that are installed directly into the plugins directory.
 

What do plug-in authors have to do?

Packaging

No changes are required to the code of existing plug-ins. However, a minor change is required for your plug-in's installation procedure. If you package your plug-in as a ZIP file, you need to have a "path" inside of the ZIP that corresponds to the directory name that you want your plug-in to use. Then, when the user unzips to the plugins directory, your JAR and other files will end up in the correct subdirectory. The Standard Extensions plugin is a good example of what such a ZIP file should look like.

It is essential that each plug-in be placed in a directory with a unique name. In order to ensure unique names, we suggest the scheme illustrated above of using a directory with an "inverted URL" that you "own" and a name for your plug-in. Typically, such a URL has been used as the package name for your plug-in.

Documentation

We encourage, but do not require you to provide both "About Box" and "Documentation" support for your plug-in. These are simply standard HTML pages and should not be difficult to create or maintain. Examples of working pages can be found in the PAL plug-in ZIP file. The names of the files that you want to appear in the About Box and documentation listings are specified in the plugin.properties file. The PAL plug-in above provides an example of this file.

Note that your "About" information will be displayed in a frame within Protégé but if you provide any clickable links on the pages, then these will fire up the user's default browser. The documentation HTML page will be displayed in the user's browser.

Dependencies on other plugins

Some plugins are (perhaps optionally) dependent on other plugins to run. The properties file of the depending plugin must list the directories of all of the other plugins on which it is dependent. It is not necessary (but harmless) to record recursive dependencies (A depends on B and B depends on C). Mutually recursive dependencies are allowed (A depends on B and B depends on A) but are probably a bad idea for other reasons.  It is not an error if a dependent plugin package is not present. However, if the dependent package is required then depending plugin will not load or run.

The lines below are an example of a dependency in properties file. The this plugin is specified as dependent upon both standard extensions and the OWL plugin.

	plugin.dependency.count=2
	plugin.dependency.0=edu.stanford.smi.protegex.standard_extensions
	plugin.dependency.1=edu.stanford.smi.protegex.owl

The result of specifying dependencies on packages which are themselves incompatible is undefined.

What does the plug-in user have to do?

Users should verify that their plug-in JARs have ended up in the right place after installation. After installing a plug-in, please check that the directory structure for the newly installed plug-in resembles the Protégé 2.1 directory structure shown above. After installing a plug-in, you should be able to find about the plug-in from the "Help | Plug-ins" and "Help | About Plugins..." menus.

Acknowledgements

Thanks go to Ian Dickinson of HP labs for originally suggesting the implementation technique for handling the "plug-in conflict" problem.