Eclipse Update Policy Control

This document describes a new Eclipse Update capability that allows large shops with many seats of Eclipse-based products to exert control over how these products are updated.

The document is related to a 3.0 plan item tracked by the following Bugzilla entry:

37702 [plan item] Improve organizational control over product updates

1. The Problem

Eclipse Update allows users to search for updates to the currently installed features. For each installed feature, Update will use the embedded URL to connect to the remote server and search for new versions. If there are updates, Eclipse allows users to initiate the install procedure. After downloading, installing and restarting the platform, new feature version is ready for use.

In companies with many users of the same Eclipse-based product (typically a commercial one), several problems can arise from this model:

  1. Updates for very large products (e.g. 500+ plug-ins) can also be large. I/T support teams may not like the idea of hundreds of developers individually downloading 500MEG updates to their individual machines. In addition to the bandwidth hit, such a large download request may fail, leading to repeated attempts and increased developers' downtime.
  2. Some companies explicitly don't want the developers downloading updates directly from the Internet. For example, they can set up a local support team that may not be ready to handle requests related to the version of the product available from the provider's update site. They may want to limit updates and fixes to the internally approved list. Ideally, they would do that by setting up 'proxy' update sites on the LAN (behind the firewall).
  3. Once updates are set in the proxy sites as above, administrators need a way of letting users know that updates are available.

2. The Proposal

The proposed solution in Eclipse 3.0 consists of three new capabilities that together address all of the above problems.

2.1 Support for creating local (proxy) update sites

First step for a product administrator would be to set up a local Eclipse update site on a server connected to the company's LAN (behind the firewall). The update site would be a subset of the product's update site on the Internet because it would contain only features and plug-ins related to the updates that the company wants applied at the moment. Technically, this site would be a regular Elipse update site with site.xml, feature and plug-in archives.

Administrators would construct this site in two ways:

  1. Product support teams would make the zip file of the update site readily available for this particular purpose. Administrators would simply need to download the zip file from the product support web page using the tool of their choice and unzip it in the local server. This approach is useful for very large zip files that require modern restartable downloading managers (those that can pick up where they left off in case of the connection problems).
  2. Eclipse Update would provide a wizard that can browse remote update sites and allow administrators to select updates and fixes to download. The behavior would be very similar to the current update search wizard up to the install point. At that juncture, Update would simply copy archives into the designated local site and update site.xml instead of commencing the installation phase. This option is fully automated and would greatly simplify administrator's task but relies on Update network connection capabilities (improved downloading reliability and performance is addressed in a different Update 3.0 plan item).

2.2 Common update policy control

Since features have Update site URL embedded, they are unaware of the local update sites set up by administrators. It is therefore important to provide redirection capability. This and other update policy settings can be set for a Eclipse product by creating an update policy file and configuring Update to use that file when searching.

The file in question can have any name, but needs to conform to standard Java properties syntax. The file can be set in Preferences>Install/Update>Automatic Updates [as of M1; final home may change for 3.0; in M1, the entry is called 'Address Mapping URL'; this will also change in subsequent milestones]. This entry field is empty by default: users may set the URL of the update policy file. This file is set up by local administrators and is shared for all the product installations. Sharing can be achieved in two ways:

A file has been chosen for two reasons: it allows central control over the update policy settings for an installed product, and it is also 'all or nothing' - individual users cannot change some aspects of the policy while keeping others.

The policy file can contain the following key/value pairs:

url-map

Syntax:

url-map.<feature ID prefix> = <local URL>
url-map.* = <default local URL for all the features>

This key is used to remap Update URLs embedded in feature manifests. When searching for new updates, Eclipse search will check the update policy (if present) and check if url-map for the matching feature prefix is specified. If a match is found, the mapped URL will be used instead of the embedded one. This way, administrators can configure Eclipse products to search for updates in the local server behind the firewall.

Several url-map entries may exist in the file. The feature prefixes may be chosen to be less or more specific. For example, to redirect all Eclipse updates, the key would be url-map.org.eclipse. Similarly, it is possible to use a complete feature ID as a prefix if redirection is required on a per-feature basis. Finally, using '*' would set up a server URL for all the features (a setting that should generally not be used unless total control is needed).

try-embedded

Syntax:

        try-embedded = (true | false) "true"

This key sets the policy regarding features for which mapped URL was not found. If 'true' (default), update search will default to the embedded URL if no matching url-map has been found in the update policy file. Setting 'false' effectively hides the embedded update URL. The default settings is recommended because it allows the primary product features to be updated from the local server, while third-party (add-on) features downloaded into the product using Eclipse Update can still by updated from the internet.

2.3 Automatic discovery of updates

The third part of the overall solution is covered by another plan item (Improve Update Manager search) but is mentioned here because it is an integral part of the solution. Automatic updates will allow Eclipse to run update search on a specified schedule (on each startup (the default), once a day, once a week etc.).

3. Conclusion

Here is the complete sequence of steps that represents the solution:

  1. Administrator allocates a server on the company LAN for hosting local product updates. Initially it contains no update sites.
  2. Administrator sets up an update policy file on that server and instructs all users to configure their products using the provided URL.
  3. As the product provider ships updates and fixes on their update sites, the administrators downloads supported updates into the local server.
  4. Automatic updates executed at the scheduled frequency picks up the local updates and informs the user
  5. User chooses to install the discovered updates

4. Schedule

Early implementation of the update policy (with redirection) is already in the regular integration builds (since M1). Wizard for creating partial local shadows of the remote update sites will appear after M2 (actual milestone not known yet).