Eclipse Update allows users to search for updates to the currently installed features. For each installed feature, Update uses 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) are also 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 already available from the provider's update site. They may want to restrict 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. Update policy to the rescue

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 Eclipse update site with site.xml, feature and plug-in archives.

Administrators would construct this site in two ways:

1. Product support teams would make a 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 provides a tool to mirror remote update sites entirely or allow administrators to select updates and fixes to download. This mirroring capability would be fully automated and would greatly simplify administrator's task but it relies on Update network connection support.

2.2 Common update policy control

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

The file in question uses XML format and can have any name. The file can be set in Preferences>Install/Update in the Update Policy field. The text field is empty by default: users may set the URL of the update policy file. The file is managed by the local administrator and is shared for all the product installations. Sharing can be achieved in two ways:

• If users install the product: users are told to open the preference page and enter the provided URL
• If administrators install the product: administrators edit the file 'plugin_customization.ini' in the primary product feature and set the default value of the 'updatePolicyFile' property as follows:
  
      org.eclipse.update.core/updatePolicyFile = <URL value>
  
  
  This will cause all the installations to have this file set by default.

The policy file must conform to the following DTD:

<?xml encoding="ISO-8859-1"?>

<!ELEMENT update-policy (url-map)*>
<!ATTLIST update-policy
>

<!ELEMENT url-map EMPTY>
<!ATTLIST url-map
    pattern    CDATA #REQUIRED
    url        CDATA #REQUIRED
>

url-map

• pattern - a string that represents prefix of a feature ID (up to and including a complete ID). A value of "*" matches all the features.
• url - a URL of the alternative update site that should be used if the feature ID begins with the pattern. If the string is emtpy, features matching pattern will not be updateable.

This element is used to override Update URLs embedded in feature manifests. When looking 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. Meanwhile, third-party features installed by Eclipse Update will continue to be updated using the default mechanism because they will not find matches in the policy.

Several url-map elements may exist in the file. Feature prefixes can be chosen to be less or more specific. For example, to redirect all Eclipse updates, the pattern attribute would be "org.eclipse". Similarly, it is possible to use a complete feature ID as a pattern if redirection is required on a per-feature basis.

Patterns in the file may be chosen to progressively narrow the potential matches. This may result in multiple matches for a given feature. In this case, the match with a longest pattern will be used. For example:

<?xml version="1.0" encoding="UTF-8"?>
<update-policy>
    <url-map pattern="org.eclipse" url="URL1"/>
    <url-map pattern="org.eclipse.jdt" url="URL2"/>
</update-policy>

In the case above, all Eclipse features will be updated from URL1, except org.eclipse.jdt that will use URL2.

Update policy files do not contain translatable strings and therefore do not require special NL handling. In general, the files should use UTF-8 encoding.

2.3 Automatic discovery of updates

The third part of the overall solution is covered by another topic 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. Summary

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

1. Administrator allocates a server on the company LAN for hosting local product updates. Initially it contains no update sites. The machine must have an HTTP server running.
2. Administrator sets up an update policy file on that server and instructs all users to set the update policy preference the provided URL.
3. As the product provider ships updates and fixes on their update sites, administrator downloads supported updates onto the local server.
4. Automatic update executed at the scheduled frequency when the client's product is up picks up the local updates and notifies the user
5. User chooses to install the discovered updates

Automatic Update Scheduler