Difference between revisions of "PluginDistribution"
m |
|||
| Line 24: | Line 24: | ||
| − | If | + | If your plugin '''depends on another plugin''' (e.g. your plugin depends on the protege-owl plugin), please read the [http://protegewiki.stanford.edu/index.php/PluginDependencies Plugin Dependencies page]. |
Latest revision as of 15:55, May 29, 2008
Tips for packaging your plug-in for distribution
In Protege versions 2.1 and higher, each plug-in resides in a separate, uniquely named subdirectory of the plugins directory and is loaded by a separate class loader. Prior to version 2.1, all plug-ins were placed at the same level in the plugins directory, which caused problems when plug-ins required incompatible versions of the same library. Thanks go to Ian Dickinson at HP Labs for originally suggesting the implementation technique for handling the "plug-in conflict" problem.
Below is a screen shot of the typical Protege directory structure:
If you package your plug-in for distribution 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 a 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.
Below is a screen shot of a Protege plug-in that has been packaged for distribution in ZIP format. Note the "Path" in the ZIP file, which allows a user to unzip the file to the correct subdirectory of the plugins directory.
If your plugin depends on another plugin (e.g. your plugin depends on the protege-owl plugin), please read the Plugin Dependencies page.
