Using Policy Files
Using Policy files for "mirror control" is obsoleted by Equinox p2, available in Eclipse 3.4.
To avoiding reaching mirrors specified for a particular update site / repository, there are two ways:
- If you are in control of the repo, you can remove the mirroring information to make the site unaware of any remote mirrors.
<site pack200="true" digestURL="http://download.eclipse.org/modeling/emf/updates/milestones/" mirrorsURL="http://www.eclipse.org/downloads/download.php?file=/modeling/emf/updates/milestones/site.xml&format=xml">
- If you are not in control of the repo, you can tell the p2 director to ignore mirrors:
Policy files allow a user to configure where to search for updates to a feature when checking for updates.
Why would you want this?
- For mirror control. With a policy file you can force your users to update from a mirror within your organization's firewall, instead of letting them choose a public mirror. This might give better performance or at least let you monitor the bits being transferred. Of course you'd have to be an Eclipse mirror first.
- For testing. If your features point to one update site (eg., for Releases) and you want to test doing an update from an old Release to a current Integration build, but that Integration build is not listed on the Releases site. For example, EMF uses http://download.eclipse.org/modeling/emf/updates/ for Releases and http://download.eclipse.org/modeling/emf/updates/site-interim.xml for all other builds (I, M, S).
- For patching. With a policy file you can update a publicly available EPL'd feature with your own custom version. Bear in mind doing so still must be done in adherence to EPL rules. See http://www.eclipse.org/legal/.
Creating the Policy File
A sample policy file is shown below:
<?xml version="1.0" encoding="UTF-8"?> <update-policy> <url-map pattern="feature.id" url="http://hostname/update/nightly/nightlySite.xml"/> </update-policy>
In this example, we save this to an XML file named "policy.xml". This is then placed next to the corresponding update site.xml. This effectively says "when I see feature with id x, instead go to update site y rather than the default". The pattern attribute is a string that represents prefix of a feature ID (up to and including a complete ID). A value of "*" matches all features. For example, a pattern of "org.eclipse" will match org.eclipse.jdt and org.eclipse.swt but not com.mycompany.myproduct
Note that the wildcard does not work embedded within a larger pattern; it can only be used by itself. For example, a pattern like "org.*" does not match all plugins that start with org
If you wanted to update all features from a non-standard update site, you could use a policy file to redirect from the default Update site to a secondary one. For example:
<?xml version="1.0" encoding="UTF-8"?> <update-policy> <url-map pattern="*" url="http://download.eclipse.org/modeling/emf/updates/site-interim.xml"/> </update-policy>
Using the Policy File
In Eclipse, navigate to
Window > Preferences > Install/Update, and paste in the URL to the policy file and hit OK, eg:
- or, for a local file:
The next time you search for updates, Eclipse will use the URL specified in the policy file, instead of what's in the feature.xml files.
An additional thought is to provide a preference page to allow the end user to choose which "release stream" they wish to subscribe to. In this case, there is a radio button that might specify "stable", "rc" and "nightly". Selecting one of these radio buttons would automatically set the policy file behind the scenes.