Difference: DpHipePluginsDeveloperManual (35 vs. 36)

Revision 362016-04-19 - JaimeSaiz

Line: 1 to 1
 
META TOPICPARENT name="DpHipePlugins" 
<-- 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).
  Tip, idea You can also share LocalStores using the Export View in HIPE. This will give you a compressed file with the pool, in the format of your choosing. Another user can import this file using the Import View, to recreate the LocalStore in his HIPE session (and in future HIPE sessions). This is simple and straightforward and there's nothing wrong with it. Plug-ins have more features, such as versions, title and description, and a plug-in can contain accompanying scripts, for example. Also, pools delivered as part of a plug-in are not installed to your LocalStore directory, they are kept in the plug-in directory, so they do not mix with your personal LocalStores. If a plug-in is published on a web-site (HTTP or FTP), then installation of a plug-in is slightly easier, since the download and unpacking are done automatically in a single step instead of two steps.
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 my

This 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 Task

To 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 and if it's in Jython, see MyFirstJythonTask on the HIPE Community Wiki. Both these pages start by explaining how to write a task in their respective language, and both pages contain a section "Turning the task into a HIPE plug-in".

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
  https://www.mysite.com/registry.xml
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.

ALERT! Warning:

Preferences cannot be read during the Jython initialization. For plugins, it means that trying to consult a preference while running the 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 initialization

Now, 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:
<
<

PluginRegistry and Plugin class

>
>

PluginRegistry and Plugin class

  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>
 
META FILEATTACHMENT attr="" autoattached="1" comment="Plug-in demonstrating adding a Help menu item" date="1301057081" name="demoHelpMenu_1.0.jar" path="demoHelpMenu_1.0.jar" size="6601" user="Main.PaulBalm" version="1"
META FILEATTACHMENT attr="h" autoattached="1" comment="Script for Google Analytics" date="1350656841" name="GoogleAnalytics.txt" path="GoogleAnalytics.txt" size="549" user="Main.DavideRizzo" version="1"
View topic | History: r38 < r37 < r36 < r35 | More topic actions...
 
This site is powered by the TWiki collaboration platform Powered by Perl