Plug-in Support in Protégé 2.1 |
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.
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.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.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.
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.
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.
Help | Plug-ins
" and "Help | About Plugins...
" menus.