Difference: DpHipePluginsDesignDocument (4 vs. 5)

Revision 52012-01-17 - PaulBalm

Line: 1 to 1
 
META TOPICPARENT name="DpHipePlugins"

Plug-in Framework Design Document

Line: 51 to 51
 

Installing plug-ins

Changed:
<
<
After the user specifies a URL where a plug-in is located, the installation will be performed completely automatically. It will be possible as well to browse for the plug-in bundle on the local file system. The installation has three phases: bootstrap, custom, and configuration. The bootstrap installation is implemented by HIPE and is executed always when a plug-in is installed, the other two phases are optional.
>
>
After the user specifies a URL where a plug-in is located, the installation will be performed completely automatically. It will be possible as well to browse for the plug-in bundle on the local file system. The installation has two phases: bootstrap and custom. The bootstrap installation is implemented by HIPE and is executed always when a plug-in is installed, the custom phase is optional.
  The plug-in directory is by default under $HOME/.hcss/apps/hipe/plugins. This means that the installed plug-ins are preserved when, for example, a new version of HIPE is installed. Plug-ins are shared between all installed HIPE versions. Plug-ins are not shared between users: The framework currently provides no mechanism for a directory with plug-ins that is shared by multiple users.
Line: 59 to 59
  The first step during the bootstrap phase to perform the first basic installation (basically, unjarring or unzipping in the plug-in directory). After this, the various contributions from the plug-in are added to HIPE: For contributed JARs, nothing special needs to be done, since they will be added to the classpath dynamically on every HIPE start-up (from the next restart on). LocalStores are added in-place to the HIPE Preferences under Data Access. This means that an entry for the LocalStore is added to the pool in the Preferences, which "points" to the LocalStore inside the plug-in. The LocalStore is not copied. The same for contributed scripts.
Deleted:
<
<
 

Installation phase 2: Custom installation

Changed:
<
<
The custom install phase allows for the plug-in author to specify a completely custom installation program. The system offers two ways of doing this: By specifying the URL of an installer that can be started using Java WebStart, or by including the installer as a Java program in the plug-in.

The WebStart URL is specified in the plug-in deployment descriptor, plugin.xml. For example, CASSIS is a program that has its own installer. This installer will be executed during this phase.

The other possibility is to specify the class name of the main class in the plugin.xml configuration file. If this main class implements the interface herschel.ia.gui.apps.plugin.Installer, then the install method of this class will be called. The advantage of this is that the install method is passed a PluginEnv object. This PluginEnv object can be used to add JAR files to the classpath. Normally this will not be necessary: Any JARs that exist in the jars directory in the plug-in are added to the classpath automatically. But if the custom installer installs JARs in a different location, you will want to access these JARs from HIPE. To do so, they must be added to the classpath. This work can also be done during the configuration phase (phase 3 -- see next paragraph).

Another advantage of having access to the PluginEnv object can be that it gives access to several plug-in attributes (custom properties, license text), though most of this will already be known and not particularly useful at this stage.

If the custom installer main class does not implement herschel.ia.gui.apps.plugin.Installer, then its main method will be called. If it doesn't have a main method either, then an error is generated.

Installation phase 3: Configuration

Finally, during the configuration phase, code is executed that is contained in the plug-in. This should be a class called Installer in the default package (i.e. not in any package) implementing an interface called herschel.ia.gui.apps.plugin.Installer. This Installer must have a public zero-argument constructor. This step can be used to inform HIPE about any external JAR archives that may have been installed during the custom install phase.

>
>
During the custom installation phase, code is executed that is contained in the plug-in. This should be a class called Installer in the default package (i.e. not in any package) implementing an interface called herschel.ia.gui.apps.plugin.Installer. This Installer must have a public zero-argument constructor. This step can be used to inform HIPE about any external JAR archives that may have been installed during the custom install phase.
  If JARs are added to the classpath this way, they are recorded in a file called bundle.xml and used when the plug-in is loaded or activated (I use loading and activation as synonyms).
Added:
>
>
The custom installation is executed on the Swing Event Dispatch Thread (the "EDT"). Unless the custom installation specifically avoids this, HIPE will be blocked and not redrawn while the custom installation is in progress. If long operations are included in the custom installation process (meaning taking more than one or a few seconds), it is advisable to off-load this work to a background thread, for example using javax.swing.SwingWorker.
 

Loading/activating plug-ins

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