The documentation on this page addresses the following topics related to plug-in support in
Protégé:
- plug-in directory structure
- plug-in loading
- how to provide documentation and an "about box" for your plug-in from within Protégé
- how to declare that your plug-in is dependent on other plug-ins
Plug-in loading & directory structure
Each Protégé plug-in is loaded by a separate class loader. This handles problems that arose in the past wherein
plug-ins required incompatible versions of the same library. Thanks go to Ian Dickinson of HP Labs for
originally suggesting this implementation technique for handling plug-in conflicts.
Every plug-in gets its own subdirectory of the
<protege_installation>/plugins
directory. For example:
Protege_3.1.1/
plugins/
ca.uvic.cs.chisel.jambalaya/
edu.stanford.smi.protegex.owl/
edu.stanford.smi.protegex.prompt/
edu.stanford.smi.protegex.rdf_backend/
edu.stanford.smi.protegex.standard_extensions/
org.algernon/
...
For installation purposes, 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.
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.