Plugin Publication

From DOC

Jump to: navigation, search

Contents

Overview

Publishing a plugin is primarily a process, aided by some tools.

Prerequisites

In general, publication of a plugin is preceded by several steps:

  1. One project (CVS module) per plugin.
  2. The plugin has been created or modified.
  3. The plugin has a tolven-plugin.xml manifest.
  4. The version number in the update manifest is greater than the version number of the same plugin already in the catalog.

Best Practice

The plugin catalog should be on a server available to those who will use the plugins in that catalog. This catalog will grow over time because it will contain all versions of all plugins. It is not recommended to send or copy the catalog (except for backup).

Activities that occur prior to publication of a new or updated plugin:

  1. The plugin will have been deployed at least once, perhaps many times, to your tolven-config/repositoryLocal. This folder is intended to hold plugins that you are modifying
  2. The plugin will have been tested (locally) in as many different configurations as appropriate.
  3. The plugin may have been informally shared with others - storing it in another repositoryLocal.

Activities just prior to upload:

  1. Prior to publication, the source code for the plugin should be committed to your CVS/SVN source code repository.
  2. Release notes for that version of the plugin written.
  3. The source code should then be tagged so that it corresponds to the to-be published plugin version. For example, com.myorg.myplugin-1.0.3 might be tagged in CVS as com_myorg_myplugin-1_0_3.

Activities following the upload process:

  1. Run tpf -getPlugins (repositoryInit) and configPhase1/2 following publication to verify that the published plugins work properly. The contents of the plugins retrieved should be identical to the plugins just published so this step is normally not testing the plugin itself but rather that the publication process worked properly.
  2. You may want to now delete the project corresponding to your published plugins from your IDE since the project is safely in CVS and the plugin is in the catalog.

Upload Process

The development environment provides several useful Ant-based procedures via the plugin plugin. The publish target in particular performs the steps needed to publish one or more plugins. In general, this process involves copying one or more plugins to the catalog download location and updating the plugins manifest at that location. The manifest is an XML file containing a reference to every plugin version in the catalog and the exact URL from which to download each individual plugin. Detailed upload steps performed by the publish ant target:

  1. Upload plugins from tolven-config/repositoryLocal to public repository (catalog)
  2. GenerateMetadata (merge) to add this/these plugins to that plugins metadata file
  3. Upload the new metadata plugin.xml to the public repository
  4. Delete the plugin(s) from repositoryLocal
  5. GenMetadata on repositoryLocal to reflect the removed plugins in the metadata plugin

Build Properties

The ant procedures use several properties in order to manage plugins. You will need to create a build.procedures file at the same directory level as the build.xml file. Each line of the properties file contains a name-value pair separated by an equal sign.

Name Default Description
admin.user admin Username of system administrator for Tolven instance on this development system.
admin.password sysadmin Password of system administrator for Tolven instance on this development system.
tolvenConfig.location c:/tolven-config Location of the permanent Tolven configuration directory.
respositoryLocal.location ${tolvenConfig.location}/repositoryLocal Location of repositoryLocal. The default is usually adequate.
tolven.devLib ${tolvenConfig.location}/devLib Location of development library of plugin jars. The default is usually adequate.
installation.location c:/tolven-RC1 Location of the current Tolven software (TPF) installation.
xslt.processor.classpath c:/saxon/saxon9he.jar Only used to generate repository listings, otherwise, can be ignored
repository.location no default Used for publishing plugins: URL of the resulting repository. This will be the location of the actual published plugin. For example, http://tolven.org/download. This is the location of the plugins.xml file, which must already exist in that location. </code>/plugins</code> will be appended to this location for the actual plugin (zip) files.
ftp.server no default Used for publishing plugins: Plugins will be *moved* from repositoryLocal to this FTP server. This is the target location where the plugin will be published. At the conclusion of the publication process, the plugin will be removed from the repositoryLocal folder. Typically specified as ftp.mydomain.com.
ftp.remoteDir no default Used for publishing plugins: FTP remote directory relative to the FTP user's root directory. For example, this property would just be . if the FTP user's root directory is the directory holding the plugins.
ftp.user no default Used for publishing plugins: FTP username with access to the publication site.
ftp.password no default Used for publishing plugins: FTP user password. For security, do not specify this property in the properties file, let ant prompt for it.

Rebuilding the plugin manifest

The plugins.xml file in the top-level folder of any plugin repository, including the plugin catalog, is critical to the management of plugins. This file is normally maintained via FTP from client development systems that publish to it.

During publication, this file is normally just updated. That is, only information about the new/updated plugins is added to the file while entries about the previous plugins remains unchanged.

If this file is corrupted or lost, it will have to be rebuilt from the individual plugin files. This process is easy and fast when done on a local machine. The following is an example of doing this on a Linux server where Apache web server is used to manage the catalog on myserver: 

cd /usr/local/tolven-RC1/bin
. ./tpfenv.sh
./genMetadata.sh -plugins /var/www/html/catalog/plugins/ -liburl http://myserver/catalog -outdir /usr/local/catalog

The plugins located in /var/www/html/catalog/plugins/ will be used to create a new manifest in the /var/www/html/catalog folder. Each plugin will contain a URL prefix of http://myserver/catalog/ pointing to where it can be downloaded from.

If your catalog is on a server that does not provide command-line access and Java, this process will have to occur on a system that does. Two additional steps are required:

  1. Download the entire plugin folder from the catalog to the system you will use to run genMetadata
  2. Upload the finished manifest (plugins.xml) file to the server.

When doing this, be sure to use the -liburl value of the actual catalog server, not the system used to run genMetadata.

Facts about Plugin PublicationRDF feed
Retrieved from "http://wiki.tolven.org/doc/index.php/Plugin_Publication"
Personal tools