Difference: DpHipePluginsDeveloperManual (32 vs. 33)

Revision 332014-02-13 - AlvarGarcia

Line: 1 to 1
 
META TOPICPARENT name="DpHipePlugins"
<-- ANALYTICS CODE - DO NOT EDIT -->
<-- Google Analytics script BEGIN -->
<-- Google Analytics script END -->
Line: 15 to 15
 

Quick Guide: Creating Simple Plug-ins

Changed:
<
<
Plug-ins can be created to do lots of fancy things, but most of the time people will want to use them to share some pools, some Jython scripts, and/or possible some Java code. These standard cases are described in this chapter.
>
>
Plug-ins can be created to do lots of fancy things, but most of the time people will want to use them to share some pools, some Jython scripts, and/or possibly some Java code. These standard cases are described in this chapter.
 One case (pools, Jython or Java) does not exclude the other; combining the steps from the different cases described here will work.

General procedure for creating a plug-in

Line: 28 to 28
 > jar cvf $HOME/myplugin_0.1.jar *
Changed:
<
<
The options to jar we used here are cvf: c for "create", v for "verbose" and f fore filename.
>
>
The options to jar we used here are cvf: c for "create", v for "verbose" and f for filename.
  If you use Windows, you can use any compression program, as long as it a can write "zip" or "jar" file format. For example, I like PeaZip.
Line: 67 to 67
 > jar cf $HOME/myplugin_0.1.jar scripts
Changed:
<
<
When this plug-in is installed, a menu item with the name of the plug-in will appear on the Tools menu. Pointing to the menu item opens a submenu with all scripts. Clicking on one of the scripts will open it in the editor.
>
>
When this plug-in is installed, a menu item with the name of the plug-in will appear in the Tools menu. Pointing to the menu item opens a submenu with all scripts. Clicking on one of the scripts will open it in the editor.
  Plug-ins support only one initialization script, but you can define multiple Tasks from a single script. The initialization script must be called plugin.py and it must be at the top or root-level of the jar or zip.
Line: 103 to 103
  This plug-in contains a JAR called filtering.jar, which in turn might contain any number of Java classes.
Changed:
<
<
For information on how to create a JAR file with your Java code, see the JAR Documentation.
>
>
For information on how to create a JAR file with your Java code, see the JAR Documentation.
  Some hints on using the plug-in: Suppose that the filtering.jar contains two classes: my.filtering.FilterA and my.filtering.FilterB. If you run HIPE with your plug-in installed, you may want to import both filters using:
Line: 145 to 145
 

Organizing your plugin.py into several shorter scripts

Changed:
<
<
If your plugin.py growse large, it becomes difficult to maintain. You can organize the plugin.py into several files and call these from the plugin.py script as follows. First, you have to find the directory in which your plug-in is installed. The next few lines assign this directory to the variable basedir:
>
>
If your plugin.py grows large, it becomes difficult to maintain. You can organize the plugin.py into several files and call these from the plugin.py script as follows. First, you have to find the directory in which your plug-in is installed. The next few lines assign this directory to the variable basedir:
 
from herschel.ia.gui.apps.plugin import PluginRegistry
Line: 174 to 174
  Here we will describe how to include compatibility information inside the plug-in itself, but if you can, it's advisable to use a plug-in version registry. This is described in the section Automatic Updates below.
Changed:
<
<
Compatible HIPE versions are specified giving a minimum version which with HIPE is compatible, and a maximum version. Experience shows that unless you already know that the latest HIPE version is incompatible, it's best to specify * as the maximum compatible version. Otherwise you will have to regularly update the maximum version to allow for new HIPE versions. It's less maintenance to act when an incompatibility is found, and specify a maximum version at that time.
>
>
Compatible HIPE versions are specified giving a minimum version with which HIPE is compatible, and a maximum version. Experience shows that unless you already know that the latest HIPE version is incompatible, it's best to specify * as the maximum compatible version. Otherwise you will have to regularly update the maximum version to allow for new HIPE versions. It's less maintenance to act when an incompatibility is found, and specify a maximum version at that time.
  Specifying a minimum version of 1.0.* and maximum version of * means that your plug-in is compatible with all builds from the 1.0 track, and all future versions. The "version" is specified using build track plus build number, not with the release number. So, for example, release 4.6 was built on the 4.0 track and it's build 1467. In the version compatibility information in plugin.xml you would specify release 4.6 as 4.0.1467. If an incompatibility is introduced in HIPE in build 1000 on the 4.0 track, then your maximum version should be set to 4.0.999.
Line: 394 to 394
 
    • An initialization script
    • A few user scripts (the scripts themselves are trivial)
    • Custom properties that are added to the HIPE configuration
Changed:
<
<
    • A custom installer for phase 2 ("custom installater" -- see advanced topics). The source code for this installer is also included, this is for your convenience only.
>
>
    • A custom installer for phase 2 ("custom installer" -- see advanced topics). The source code for this installer is also included, this is for your convenience only.
 
    • A license

For HIPE component developers: Working with plug-ins in HIPE

 
This site is powered by the TWiki collaboration platform Powered by Perl