platform-update-home/doc/working/update-policy.html

Parent Directory | Revision Log | Patch

-revision 1.4, Tue Jun 24 01:18:52 2003 UTC
+revision 1.5, Wed Jun 25 01:33:04 2003 UTC
 Line 8
  item] Improve organizational control over product updates</p>
  <h2>1. The Problem</h2>
  <p>Eclipse Update allows users to search for updates to the currently installed
- features. For each installed feature, Update will use the embedded URL to
+ 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.</p>
  <p>In companies with many users of the same Eclipse-based product (typically a
  commercial one), several problems can arise from this model:</p>
  <ol>
-   <li>Updates for very large products (e.g. 500+ plug-ins) can also be large.
+   <li>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
 Line 23
    <li>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
+     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).</li>
    <li>Once updates are set in the proxy sites as above, administrators need a
 Line 31
  </ol>
  <h2>2. The Proposal</h2>
  <p>The proposed solution in Eclipse 3.0 consists of three new capabilities that
- together address all of the above problems. </p>
+ together address the above problems. </p>
  <h3>2.1 Support for creating local (proxy) update sites</h3>
  <p>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.</p>
+ regular Eclipse update site with site.xml, feature and plug-in archives.</p>
  <p>Administrators would construct this site in two ways:</p>
  <ol>
-   <li>Product support teams would make the zip file of the update site readily
+   <li>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
 Line 53
    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
+   This mirroring capability would be fully automated and would greatly simplify administrator's task
-   but relies on Update network connection capabilities (improved downloading
+   but it relies on Update network connection support (improved downloading
    reliability and performance is addressed in a different Update 3.0 plan item).</li>
  </ol>
  <h3>2.2 Common update policy control</h3>
- <p>Since features have Update site URL embedded, they are unaware of the local
+ <p>Since features have Update site URL embedded in the manifest, they are unaware of the local
- update sites set up by administrators. It is therefore important to provide <b>
+ update sites set up by the administrators. It is therefore important to provide <b>
  redirection capability</b>. This and other update policy settings can be set for
- a Eclipse product by creating an update policy file and configuring Update to
+ an Eclipse product by creating an update policy file and configuring Update to
  use that file when searching.</p>
- <p>The file in question can have any name, but needs to conform to standard Java
+ <p>The file in question uses XML format and can have any name. The file can be set in <b>
- properties syntax. The file can be set in <b>
+ Preferences&gt;Install/Update</b><font color="#0000FF"> </font>in the <b>Update
- Preferences&gt;Install/Update&gt;Automatic Updates</b> <font color="#0000FF">[as of
+ Policy</b> group. The text field
- M1; final home may change for 3.0; in M1, the entry is called 'Address Mapping
+ is empty by default: users may set the URL of the update policy file. The file
- URL'; this will also change in subsequent milestones]</font>. This entry field
+ is managed by the local administrator and is shared for all the product
- 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:</p>
  <ul>
    <li>If users install the product: users are told to open the preference page
-Line 78
+Line 76
    in the primary product feature and set the default value of the 'updatePolicyFile'
    property as follows:<br>
    <br>
- &nbsp;&nbsp;&nbsp; <code>org.eclipse.update.core/updatePolicyFile = &lt;URL value&gt;
+ &nbsp;&nbsp;&nbsp; <code>org.eclipse.update.core/updatePolicyFile = &lt;URL value&gt;<br>
-   </code><br>
+   </code><font color="#0000FF">[this does not work yet]</font><br>
    <br>
-   This will cause all the installation to have this file set by default.</li>
+   This will cause all the installations to have this file set by default.</li>
  </ul>
- <p>A file has been chosen for two reasons: it allows central control over the
+ <p>File-based mechanism 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.</p>
- <p>The policy file can contain the following key/value pairs:</p>
+ <p>The policy file must conform to the following DTD (note that the syntax is
- <h4>url-map</h4>
+ subject to change up to the 3.0 API freeze):</p>
- <p>Syntax:</p>
  <blockquote>
-   <pre>url-map.&lt;feature ID prefix&gt; = &lt;local URL&gt;
+   <p><tt>&lt;?xml encoding=&quot;ISO-8859-1&quot;?&gt;</tt>
- url-map.* = &lt;default local URL for all the features&gt;</pre>
+   <p><tt>&lt;!ELEMENT update-policy (url-map)*&gt;</tt><br>
+   <tt>&lt;!ATTLIST update-policy</tt><br>
+   <tt>&gt;</tt></p>
+   <p><tt>&lt;!ELEMENT url-map EMPTY&gt;<br>
+   &lt;!ATTLIST url-map<br>
+   &nbsp;&nbsp;&nbsp; pattern&nbsp;&nbsp;&nbsp; CDATA #REQUIRED<br>
+   &nbsp;&nbsp;&nbsp; url&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CDATA
+   #REQUIRED<br>
+   &gt;</tt></p>
  </blockquote>
- <p>This key is used to remap Update URLs embedded in feature manifests. When
+ <h4>url-map</h4>
- searching for new updates, Eclipse search will check the update policy (if
+ <ul>
+   <li><b>pattern</b> - a string that represents prefix of a feature ID (up to
+     and including a complete ID)</li>
+   <li><b>url</b> - a URL of the alternative update site that should be used if
+     the feature ID begins with the pattern</li>
+ </ul>
+ <p>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 <b>url-map</b> for the matching feature prefix is
- specified. If a match is found, the mapped URL will be used instead of the
+ specified. If a match is found, the mapped URL will be used <b> instead</b> of the
  embedded one. This way, administrators can configure Eclipse products to search
- for updates in the local server behind the firewall. </p>
+ for updates in the local server behind the firewall. Mealwhile, third-party
- <p>Several url-map entries may exist in the file. The feature prefixes may be
+ features installed by Eclipse Update will continue to be updated using the
+ default mechanism because they will not find matches in the policy.</p>
+ <p>Several <b>url-map</b> 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 key would be <code>url-map.org.eclipse</code>. Similarly, it is
+ updates, the pattern attribute would be <code>&quot;org.eclipse&quot;</code>. Similarly, it is
- possible to use a complete feature ID as a prefix if redirection is required on
+ possible to use a complete feature ID as a pattern if redirection is required on
- a per-feature basis. Finally, using '*' would set up a server URL for all the
+ a per-feature basis.</p>
- features (a setting that should generally not be used unless total control is
+ <p>Patterns in the file may be chosen to progressively narrow the potential
- needed).</p>
+ matches. This may result in multiple matches for a given feature. In this case,
- <p>In case of multiple matches, the one with a longer pattern will be used. For
+ the <b>match with a longest pattern</b> will be used. For
  example:</p>
  <blockquote>
- <pre>url-map.org.eclipse = URL1
+ <pre>&lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&gt;
- url-map.org.eclipse.jdt = URL2</pre>
+ &lt;update-policy&gt;
+         &lt;url-map pattern=&quot;org.eclipse&quot; url=&quot;URL1&quot;/&gt;
+         &lt;url-map pattern=&quot;org.eclipse.jdt&quot; url=&quot;URL2&quot;/&gt;
+ &lt;/update-policy&gt;</pre>
  </blockquote>
- <p>In the case above, all Eclipse features will be updated from URL1, except
+ <p>In the case above, all Eclipse features will be updated from URL1, except <code>org.eclipse.jdt</code> that will use URL2.</p>
- those starting with <code>org.eclipse.jdt</code> that will use URL2.</p>
+ <p>Update policy files do not contain translatable strings and therefore do not
- <h4>try-embedded</h4>
+ require special NL handling. In general, the files should use UTF-8 encoding.</p>
- <p>Syntax:</p>
- <p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <code>try-embedded = (true | false)
- &quot;true&quot;</code></p>
- <p>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 <code>url-map</code> 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.</p>
  <h3>2.3 Automatic discovery of updates</h3>
  <p>The third part of the overall solution is covered by another plan item (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=37684">Improve
  Update Manager search</a>) but is mentioned here because it is an integral part
-Line 133
+Line 140
  specified schedule (on each startup (the default), once a day, once a week
  etc.). </p>
  <h2>3. Conclusion </h2>
- <p>Here is the complete sequence of steps that represents the solution:</p>
+ <p>Here is the complete sequence of steps that comprise the solution:</p>
  <ol>
    <li>Administrator allocates a server on the company LAN for hosting local
-   product updates. Initially it contains no update sites.</li>
+   product updates. Initially it contains no update sites. The machine must have
+     an HTTP server running.</li>
    <li>Administrator sets up an update policy file on that server and instructs
-   all users to configure their products using the provided URL.</li>
+   all users to set the update policy preference the provided URL.</li>
-   <li>As the product provider ships updates and fixes on their update sites, the
+   <li>As the product provider ships updates and fixes on their update sites,
-   administrators downloads supported updates into the local server.</li>
+     administrator downloads supported updates onto the local server.</li>
-   <li>Automatic updates executed at the scheduled frequency picks up the local
+   <li>Automatic update executed at the scheduled frequency when the client's
-   updates and informs the user</li>
+     product is up picks up the local
+   updates and notifies the user</li>
    <li>User chooses to install the discovered updates</li>
  </ol>
  <h2>4. Schedule</h2>
  <p>Early implementation of the update policy (with redirection) is already in
- the regular integration builds (since M1). Wizard for creating partial local
+ the regular integration builds (since M1) but expect the actual update policy
+ DTD to be in flux at least until M2. Wizard for creating partial local
  shadows of the remote update sites will appear after M2 (actual milestone not
  known yet).</p>

 Legend:



Removed from v.1.4
 


changed lines


 
Added in v.1.5
 Legend:



Removed from v.1.4
 


changed lines


 
Added in v.1.5
-Removed from v.1.4
+Added in v.1.5

help@eclipse.org	ViewVC Help
Powered by ViewVC 1.0.3