USERS
DEVELOPERS
 support for plug-ins in protégé

The documentation on this page addresses the following topics related to plug-in support in Protégé:



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.