Revision of Simple Interface For Plugin Installation and Upgrade from Mon, 2006-05-08 06:31

Simple Interface For Plugin Installation and Upgrade

Problem: Manual Installation Process

Installing a plugin takes two or three steps, depending upon the platform and installed software.
  1. Unzip the plugin package
  2. Copy the generated directory into the “demo” or “plugins” folder
  3.  Run the integrator task
Steps 1 and 2 may be combined on many platforms, if the user knows how to “target” the unzip of a directory appropriately.

This process is actually pretty error prone. Reported user mistakes include:

  • creating a directory and then unzipping the package into it (resulting in an extra directory)
  • running the integrator task in the wrong directory

Problem: Automated Installation Process

A software developer or system administrator wishes to make scripts that will automatically install a set of plugins. Today, this installation process necessarily depends upon the directory structure of the DITA Toolkit. This makes reorganizations of the toolkit potentially backwards incompatible.

Proposal

Given a properly configured DITA toolkit, installing a plugin should be a single step, like

    java -jar lib/dost.jar /plugin:”c:\My Download Files\FrameMaker_adapter.zip”

No matter what the directory structure of future DITA toolkits, this command line will remain invariant and will copy the right files to the right places.

This implies a fixed structure for plugins. The proposed structure is as described below.

Plugin Structure

A DITA toolkit plugin is a zip file consisting of a single top-level directory. This top-level directory must contain a file called “plugin.xml”. It will typically contain main other files but this standard does not address the structure of those files.
XML.org Focus Areas: BPEL | DITA | ebXML | IDtrust | OpenDocument | SAML | UBL | UDDI
OASIS sites: OASIS | Cover Pages | XML.org | AMQP | CGM Open | eGov | Emergency | IDtrust | LegalXML | Open CSA | OSLC | WS-I