Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
<-- ANALYTICS CODE - DO NOT EDIT --> <-- Google Analytics script BEGIN --> <-- Google Analytics script END --> | ||||||||
Line: 25 to 25 | ||||||||
On Unix you can use the jar facility from the bin directory of the JDK to create jar-files. I recommend to cd to the directory where you have prepared your plug-in and create the jar-file in a different place, as follows: | ||||||||
Changed: | ||||||||
< < | > jar cvf $HOME/myplugin_0.1.jar * | |||||||
> > | > jar cvf $HOME/myplugin_0.1.jar * | |||||||
The options to jar we used here are cvf : c for "create", v for "verbose" and f for filename. | ||||||||
Line: 44 to 43 | ||||||||
> mkdir pools > cp -r $HOME/.hcss/lstore/poolA pools > cp -r $HOME/.hcss/lstore/poolB pools | ||||||||
Changed: | ||||||||
< < | > jar cf $HOME/myplugin_0.1.jar pools | |||||||
> > | > jar cf $HOME/myplugin_0.1.jar pools | |||||||
You probably will want to name your plug-in differently than "myplugin" though -- give it a name that says something about its contents. To change the name of the plug-in, you can just rename the file. | ||||||||
Changed: | ||||||||
< < | When the plug-in is installed, the pools will appear in the Data Access section of the preferences (see Edit --> Preferences). | |||||||
> > | When the plug-in is installed, the pools will appear in the Data Access section of the preferences (see Edit > Preferences). | |||||||
![]() | ||||||||
Line: 64 to 62 | ||||||||
> mkdir scripts > cp ~/work/scriptsForPlugin/*.py scripts | ||||||||
Changed: | ||||||||
< < | > jar cf $HOME/myplugin_0.1.jar scripts | |||||||
> > | > jar cf $HOME/myplugin_0.1.jar scripts | |||||||
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. | ||||||||
Line: 76 to 73 | ||||||||
> mkdir scripts > cp ~/work/myTasks.py plugin.py | ||||||||
Changed: | ||||||||
< < | > jar cf $HOME/myplugin_0.1.jar plugin.py | |||||||
> > | > jar cf $HOME/myplugin_0.1.jar plugin.py | |||||||
This plugin.py script is similar in function to the __init__.py script that is contained in many of the Java packages in the HCSS. However, the __init__.py must have some obligatory lines of code, which are not required for the plugin.py script. | ||||||||
Line: 88 to 84 | ||||||||
> mkdir jars > cp ~/work/out/library.jar jars | ||||||||
Changed: | ||||||||
< < | > jar cf $HOME/myplugin_0.1.jar jars | |||||||
> > | > jar cf $HOME/myplugin_0.1.jar jars | |||||||
Note that the JARs are included integrally in the plug-in JAR; you should not unpack your JARs with Java code and include the loose class files in the plug-in JAR. To clarify further, if you get a listing from your plug-in JAR using jar tf plugin-1.0.jar , you might get a listing like this: | ||||||||
Changed: | ||||||||
< < | META-INF/ | |||||||
> > | META-INF/ | |||||||
META-INF/MANIFEST.MF jars/ jars/filtering.jar | ||||||||
Line: 104 to 98 | ||||||||
This plug-in contains a JAR called filtering.jar , which in turn might contain any number of Java classes.
For information on how to create a JAR file with your Java code, see the JAR Documentation![]() | ||||||||
Deleted: | ||||||||
< < |
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:
from my.filters import *
And this may give you an error:
<type 'exceptions.ImportError'>: No module named myThis can be solved with the command: import my
After that, "normal imports" like from my.filters import * will work.
To help your users, you may want to add the statement import my to your plugin.py file, so that it is already executed when HIPE starts. | |||||||
How to create a plug-in with a TaskTo easiest way to avoid the hassle that is involved in "making a new task work in HIPE", is to create a plug-in with the task inside. If your Task is in Java, please refer to MyFirstJavaTask![]() ![]() | ||||||||
Line: 130 to 107 | ||||||||
If you want to create a plug-in that has an initialization script, some user scripts and a handful of pools, the easiest thing is to create a separate directory. Copy everything in there (the scripts directory, pools directory, etc) and create a zip or jar with everything: | ||||||||
Changed: | ||||||||
< < | > jar cf $HOME/myplugin_0.1.jar * | |||||||
> > | > jar cf $HOME/myplugin_0.1.jar * | |||||||
What you must avoid / Invalid plug-ins | ||||||||
Line: 153 to 128 | ||||||||
name = 'myPluginName' # fill in the name of the plug-in here plugin = reg.get(name) | ||||||||
Changed: | ||||||||
< < | basedir = plugin.pluginDir.absolutePath | |||||||
> > | basedir = plugin.pluginDir.absolutePath | |||||||
Using this base directory, you can execute scripts in your plug-in using the execfile command:
execfile(basedir + '/a.py') execfile(basedir + '/b.py') | ||||||||
Changed: | ||||||||
< < | execfile(basedir + '/c.py') | |||||||
> > | execfile(basedir + '/c.py') | |||||||
Note that you can store these scripts in subdirectories within your plug-in as well. | ||||||||
Line: 205 to 177 | ||||||||
| ||||||||
Changed: | ||||||||
< < | ||||||||
> > | ||||||||
All of the elements of this XML file are optional, except <plugin> . If you're not interested in any of the elements, just don't add this file. | ||||||||
Line: 235 to 206 | ||||||||
class ImportScanAmorphosTask(Task,ExternalHelp): # ... def getHelpURL(self): | ||||||||
Changed: | ||||||||
< < | return String("http://herschel.esac.esa.int/twiki/bin/view/Public/ScanAmorphosPlugin") | |||||||
> > | return String("http://herschel.esac.esa.int/twiki/bin/view/Public/ScanAmorphosPlugin") | |||||||
Thus, by typing in console | ||||||||
Changed: | ||||||||
< < | help(importScanAmorphos)
pressing the task's GUI help button, or selecting the task in the Tasks view and selecting the Help -> Help (External) menu option, your browser will open the web page you have provided. | |||||||
> > | help(importScanAmorphos)
pressing the task's GUI help button, or selecting the task in the Tasks view and selecting the Help -> Help (External) menu option, your browser will open the web page you have provided.
Using preferences in your plug-in | |||||||
Added: | ||||||||
> > | A plug-in can use preferences as any other code integrated in HIPE.
It can also register custom preferences panels, which will be included in the preferences tree that is shown when executing Edit > Preferences.
![]() plugin.py would throw an IllegalStateException , for example:
from herschel.ia.gui.kernel.prefs import UserPreferences print UserPreferences.get("MyPluginCategory", "myPreference") # Exception that prevents the plugin from correctly finalizing its initializationNow, preferences can be accessed once HIPE start-up has finished. For that, schedule it like in this example: from herschel.ia.gui.kernel import SiteApplication from java.lang import Runnable class PreferenceReader(Runnable): def run(self): from herschel.ia.gui.kernel.prefs import UserPreferences print UserPreferences.get("MyPluginCategory", "myPreference") SiteApplication.getSite().runWhenStarted(PreferenceReader(), False) | |||||||
Using your plug-in in HIPE batch mode (was: jylaunch) | ||||||||
Line: 249 to 244 | ||||||||
The jylaunch command was replaced in HIPE 11 by "HIPE batch mode", which is invoked simply by calling the hipe command, followed by the filename of the script to execute.
Plug-ins can be used in the same way in batch mode as from the GUI, with the same caveats as processing scripts. HIPE in batch mode does not load all Herschel classes on start-up, like the GUI does, to save time. The HIPE GUI executes the following command at start-up: | ||||||||
Deleted: | ||||||||
< < | ||||||||
Changed: | ||||||||
< < | from herschel.all import * | |||||||
> > | from herschel.all import * | |||||||
The fact that in batch mode this command is not executed, can lead to different problems. A typical error caused by not having imported all Herschel code is: | ||||||||
Deleted: | ||||||||
< < | ||||||||
Changed: | ||||||||
< < | NameError: TableDataset | |||||||
> > | NameError: TableDataset | |||||||
TableDataset is a class that is readily imported after start-up, in the GUI, but not in batch mode. | ||||||||
Line: 311 to 301 | ||||||||
// to get the Class object: Class<?> c = ObjectUtil.getClass("my.package.MyClass"); // or to create an object of this class | ||||||||
Changed: | ||||||||
< < | my.package.MyClass object = ObjectUtil<my.package.MyClass>.newInstance("my.package.MyClass"); | |||||||
> > | my.package.MyClass object = ObjectUtil<my.package.MyClass>.newInstance("my.package.MyClass"); | |||||||
The newInstance method uses the default constructor. If you need to use a different constructor, use the Class object. | ||||||||
Line: 371 to 359 | ||||||||
Changed: | ||||||||
< < | ||||||||
> > | ||||||||
The above example registry file lists two versions of a plug-in called "example1": Version 2.2 and 2.3. Version 2.2 is stated to be compatible with HIPE v5.0 (the user release, not earlier builds) and also all builds of the 6.0 track. Version 2.3 is compatible version HIPE release 6.0 starting RC1 and all future versions of HIPE. | ||||||||
Changed: | ||||||||
< < | Contrary to earlier recommendations, I now recommend to specify that the latest (current) version of your plug-in is compatible with all future versions, by specifying an asterisk: . If it it turns out that at some version of HIPE the plug-in does not work anymore, users can disable it manually and/or you can update the registry file to specify the new maximum. Experience shows this works better than specifying the current HIPE version as the maximum version, and updating it when new HIPE versions come out. Plug-ins tend to get blocked inadvertently. | |||||||
> > | Contrary to earlier recommendations, I now recommend to specify that the latest (current) version of your plug-in is compatible with all future versions, by specifying an asterisk: * . If it it turns out that at some version of HIPE the plug-in does not work anymore, users can disable it manually and/or you can update the registry file to specify the new maximum. Experience shows this works better than specifying the current HIPE version as the maximum version, and updating it when new HIPE versions come out. Plug-ins tend to get blocked inadvertently. | |||||||
If version 2.4 of the plug-in is released, it can also simply be added to the registry. HIPE instances having the plug-in installed will suggest the update to the user, if the version of HIPE is compatible. | ||||||||
Line: 403 to 390 | ||||||||
Once plug-ins have been installed and are started, HIPE components can find them in the Plug-in Registry (for example, the Plug-ins Panel that can be opened from the Tools menu). | ||||||||
Changed: | ||||||||
< < | | |||||||
> > | | |||||||
The Plug-in Registry, implemented by the PluginRegistry class, is a singleton that allows access to all plug-ins currently installed (latest versions only). The elements that in the registry are of the Plugin class. They are keyed by the plug-in name and sorted alphabetically. | ||||||||
Line: 421 to 408 | ||||||||
Original author: Paul Balm - 27 Aug 2010 | ||||||||
Added: | ||||||||
> > | ||||||||
Deleted: | ||||||||
< < | ||||||||
<-- COMMENT BOX CODE - DO NOT EDIT --> | ||||||||
Added: | ||||||||
> > | ||||||||
Changed: | ||||||||
< < | blog comments powered by Disqus | |||||||
> > |
blog comments powered by Disqus![]() | |||||||
<-- END OF COMMENT BOX CODE --> | ||||||||
Changed: | ||||||||
< < | ||||||||
> > |
</verbatim> | |||||||
|