Difference between revisions of "PluginDependencies"

From Protege Wiki
Jump to: navigation, search
(fixed broken links)
(fixed link to go to correct page)
 
Line 52: Line 52:
  
  
<strong>See Also: [[Protege3DevDocs|How to make your plug-in's documentation available to users from within Protege]]</strong>
+
<strong>See Also: [[ProvidePluginDocs|How to make your plug-in's documentation available to users from within Protege]]</strong>

Latest revision as of 17:25, January 27, 2009

Instructions for declaring dependencies between Protege plug-ins

Each Protege plug-in is loaded by a separate class loader and resides in a separate, uniquely named subdirectory of the Protege "plugins" directory. To follow is an example of what the typical directory structure looks like:

<protege-install-dir>
    plugins/
        edu.stanford.smi.protegex.datamaster/
            datamaster.jar
            plugin.properties
            ...
        edu.stanford.smi.protegex.owl/
            jena.jar
            jdom.jar
            protege-owl.jar
            plugin.properties
            ...
        edu.stanford.smi.protegex.standard_extensions/
            JGo.jar
            JGoLayout.jar
            standard-extensions.jar
            plugin.properties
            ...


If you are developing a Protege plug-in and you need to declare your plug-in as dependent on other plug-ins, you must provide a "plugin.properties" file in the root directory of your plug-in. The plugin.properties file is a text file in which plug-in authors can:


  • declare dependencies on other plug-ins
  • specify "About Box" information for your plug-in
  • specify the location of your plug-in's documentation


This article only discusses the syntax for declaring dependencies. If you want to specify About Box information or the location of your plug-in's documentation, please see the Wiki article entitled "How to make your plug-in's documentation available to users from within Protege".


The plugin.properties file of the depending plug-in must list the directories of all of the other plug-ins on which it is dependent. It is not necessary (but harmless) to record recursive dependencies, e.g., 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 plug-in package is not present. However, if the dependent package is required, then depending plug-in will not load or run.


Below is an example of a dependency in a plugin.properties file. The PROMPT plug-in has declared itself as being dependent upon Protege-OWL, the RDF Backend plug-in, and the Changes Tab plug-in:


plugin.dependency.count=3
plugin.dependency.0=edu.stanford.smi.protegex.owl
plugin.dependency.1=edu.stanford.smi.protegex.rdf_backend
plugin.dependency.2=edu.stanford.smi.protegex.changes


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


See Also: How to make your plug-in's documentation available to users from within Protege