Updating a product or extension

By following the prescribed procedures for packaging and installing products, we can take advantage of platform provisioning support, which treats products and extensions in a uniform way and allows users to discover and install updated versions of products and extensions.

Before looking at the implementation of such a server, it's important to revisit some important concepts:

• The platform provides a framework for defining features and software sites.  The platform itself defines a concrete implementation of features and sites.  This concrete implementation is what allows the platform to upgrade and install additional features.
• The platform software site can be used to update products by installing new versions of features.  It can also be used to install or update extensions by adding or upgrading features.   This is only possible for products and extensions that conform to the platform's concrete implementation of features and sites and conform to the appropriate install guidelines.
• Developers are free to use native installers and uninstallers to upgrade their own products and extensions without regard to sites and the platform update support.

That said, what do we do if we want to fully participate in the platform implementation of product updating and use its update server?

Feature and plug-in packaging

The previous example product and extension directory structures show how features and plug-ins are laid out once they are installed.  In order to install features using the software site, the features must be packaged in a feature archive file.  This is described in Feature Archive Files.

Plug-ins and fragments must be packaged according to the format described in Plug-in Archive Files.

Software site layout

The software site must be a URL-accessible server with a fixed layout.  The list of available features and plug-ins provided by the server is described in a site map file, content.xml.  The server URL can be specified as a full URL to the site map file, or a URL of a directory path containing the site map.  Prefer using the directory path as this will allow for future changes to the software site format.   The site map file contains a list of all the available features and the location of the feature archives on the server.  It also describes the locations of the plug-in archives that are referenced in the feature manifest.

A simple site layout for our example web product and extension could look something like this:

<site root>/
	artifacts.jar (compressed p2 artifact repository - present in p2 optimized site)
	content.jar (compressed p2 metadata repository - present in p2 optimized site)
	features/	(contains feature archive files)
		com.example.acme.acmefeature_1.0.1.jar
		com.example.betterwebs.betterfeature_1.0.1.jar
		...
	plugins/	(contains plug-in archive files)
		com.example.acme.acmefeature_1.0.1.jar
		com.example.acme.acmewebsupport_1.0.3.jar
		com.example.betterwebs.betterfeature_1.0.1.jar
		com.example.betterwebs.betterwebsupport_1.0.1.jar
		...

Update servers

An Eclipse project software site is provided for updating the platform itself. In addition, the platform update UI allows users to maintain a list of software sites that can be searched for new features. Any site that conforms to the specified update server layout may be added to the list. Users can choose to manually or automatically search for additional features or upgrades to their installed features.

Software sites can be created and manipulated by creating an "update site" project in PDE, or by using the publishing and repository manipulation command line tools and Ant tasks.