Integration with Extension Manager

From Apache OpenOffice Wiki
Jump to: navigation, search

The Extension Manager is a tool for deploying components, configuration data and macro libraries (see chapter Extensions). It provides a convenient mechanism for macro developers to distribute their macros.

The scripting framework supports deployment of macros in extensions. Currently only extensions for the media type "application/" are supported. Macros deployed in extensions of this media type must use the ScriptingFramework storage scheme and parcel-descriptor.xml to function correctly. An implementation of the service is provided which supports deployment of macro libraries of media type "application/" with the Extension Manager.

Documentation note.png Basic macros are handled via a separate media type "application/" and hence handled by a different mechanism.

Overview of how ScriptingFramework integrates with the Extension Manager API

Registration of macro library using Package Manager


Macro libraries contained in extensions are registered by the Extensions Manager. It informs the LanguageScriptProvider by calling its insertByName() method. The LanguageScriptProvider persists the registration of the macro library in order to be aware of registered libraries when is restarted at a future time.


Deregistration of a macro library contained in an extension is similar to the registration process described above, the Extension Manager informs the LanguageScriptProvider that a macro library has been removed by calling its removeByName() method. The LanguageScriptProvider removes the macro library from its persisted store of registered macro libraries.

Implementation of LanguageScriptProvider with support for Package Manager


In order for the LanguageScriptProvider to handle macro libraries contained in UNO packages with media type "application/" it's initialize() method must be able to accept a special location context that indicates to the LanguageScriptProvider that it is dealing with extensions.

Location context
"user:uno_packages" String. Denotes the user installation deployment context.
"share:uno_packages" String. Denotes the share installation deployment context.

On initialization the LanguageScriptProvider needs to determine what macro libraries are already deployed by examining its persistent store.

Documentation note.png LanguageScriptProviders created by implementing the abstract Java helper class do not need to concern themselves with storing details of registered macro libraries in extensions. This support is provided automatically. An XML file called unopkg-desc.xml contains the details of deployed UNO script packages . This file located in either <OfficePath>/user/Scripts or <OfficePath>/share/Scripts depending on the installation deployment context.

As of OOo 3.3 the file is called shared-extension-desc.xml, for shared extetensions, and user-extension-desc.xml for user extensions. Both are in <UserInstallation>/user/Scripts.

The DTD for unopkg-desc.xml follows

<?xml version="1.0" encoding="UTF-8"?>
<!-- DTD for unopkg-desc for Scripting Framework Project -->
<!ELEMENT package EMPTY>
<!ELEMENT language (package+)>
<!ELEMENT unopackages (language+)>
<!ATTLIST language
<!ATTLIST package

An example of a sample an uno-desc.xml file is shown below.

<unopackages xmlns:unopackages="unopackages.dtd">
  <language value="BeanShell">
    <package value="
      $" />
  <language value="JavaScript">
    <package value="
      $" />
    <package value="
      $" />

A LanguageScriptProvider that does not use the Java abstract helper class will need to persist the extensions deployed for the supported language themselves.

The LanguageScriptProvider additionally needs to support the interface which supports the following methods.

  void insertByName( [in] string aName, 
                     [in] any aElement ) 
  void removeByName( [in] string Name )

On registration of an extension containing scripts the LanguageScriptProvider's insertByName() method is called with aName containing the URI to a macro library contained in the extension and aElement contains an object implementing Note that the URI contains the full path to the macro library contained in the extension. For example, if the library is named my macros then the path includes the mymacros directory.

On deregistration of an extension containing scripts the LanguageScriptProvider's removeByName() method is called with aName containing the URL to a macro library to be de-registered. interface itself inherits from which supports the following method

  boolean hasByName( [in] string aName )

To determine whether the macro library in an extension is already registered the LanguageScriptProvider's hasByName() is called with aName containing the URL to the script library. The other methods of the interfaces inherited by are omitted for brevity and because they are not used in the interaction between the Extension Manager and the LanguageScriptProvider. A Developer however still must implement these methods.

Implementation of the BrowseNode service

The LanguageScriptProvider created for an installation deployment context needs to expose the macro and macro libraries that it is managing. How this is achieved is up to the developer. A LanguageScriptProviders created by extending the Java abstract helper class creates nodes for each extension that contain macro libraries for the supported language . Each extension node contains the macro library nodes for the supported language and those nodes in turn contain macro nodes.

An alternative implementation could merge the macro libraries into the existing tree for macro libraries and not distinguish whether the macros are located in an extension or not. This is loosely the approach taken for Basic.

Example of creating a extension containing a macro library suitable for deploying with Extension Manager.The following example shows how to create an UNO package from the Beanshell macro library Capitalize. This macro library is located in the <OfficeDir>/share/beanshell/Capitalize directory of a installation . The extension created will be deployable using the Extension Manager .

First create a scratch directory for example called temp. Copy the macro library directory and its contents into temp. In temp create a sub-directory called META-INF and within this directory create a file called manifest.xml.

 <Dir> Temp
 |-<Dir> Capitalise
 | |
 | |--parcel-desc.xml
 | |--capitalise.bsh 
 |-<Dir> META-INF

The contents of the manifest.xml file for the Capitalize macro library are as follows

  <?xml version="1.0" encoding="UTF-8"?>
  <!DOCTYPE manifest:manifest PUBLIC "-// Manifest 1.0//EN" "Manifest.dtd">
  <manifest:manifest xmlns:manifest="">
  <manifest:file-entry manifest:media-type="application/" manifest:full-path="Capitalise/"/>

Next create a zip file containing the contents (but not including ) the temp directory. The name of the file should have the extension ".oxt" e.g. Capitalise.oxt.

Deploying a macro library contained in an extension.To deploy the extension you need to use the Extension Manager (see chapter Extensions). Once the extension has been deployed successfully the macro will be available for assignment or execution.

Content on this page is licensed under the Public Documentation License (PDL).
Personal tools
In other languages