platform-update-home/doc/eclipse_update_packaging.html

Parent Directory | Revision Log | Patch

-revision 1.12, Thu Jan  2 14:10:27 2003 UTC
+revision 1.13, Mon Jan 13 19:01:27 2003 UTC
 Line 31
     </li>
     <li><small>2.0.15</small>
      <ul>
-        <li><small>added &lt;site&gt;&lt;feature&gt; os,arch,nl,ws,patch tag</small></li>
+         <li><small>added &lt;site&gt;&lt;feature&gt; os,arch,nl,ws,patch
+ tag</small></li>
      </ul>
                         </li>
-Line 80
+Line 81
    <ul>
       <li> <font size="-1">&lt;site&gt; &lt;feature&gt; changes - additional
-  markup to optionally expose feature identification information to speed up
+   markup to optionally expose feature identification information to speed
-  searches</font></li>
+ up  searches</font></li>
        <li> <font size="-1">removed obsolete text</font></li>
        <li> <font size="-1">web-triggered update not in 2.0</font></li>
        <li> <font size="-1">no assist in 2.0 for license/ "key file" handling
-Line 116
+Line 117
    <ul>
       <li> <font size="-1">general text cleanup</font></li>
-       <li> <font size="-1">&lt;feature&gt;&lt;group&gt; support removed (will
+        <li> <font size="-1">&lt;feature&gt;&lt;group&gt; support removed
-   not be in Eclipse 2.0)</font></li>
+ (will   not be in Eclipse 2.0)</font></li>
        <li> <font size="-1">arch= support added to &lt;feature&gt; and &lt;feature&gt;&lt;plugin&gt;</font></li>
        <li> <font size="-1">os=/ arch=/ ws=/ nl= added to &lt;fetaure&gt;&lt;data&gt;</font></li>
        <li> <font size="-1">&lt;site url=""&gt; new semantics</font></li>
-Line 183
+Line 184
       This document outlines the support for managing the delivery of function
    within the Eclipse platform. Also refer to the "<a
   href="http://www.eclipse.org/legal/updatemanager.html"> Eclipse.org Update
-  Manager Agreement</a> " for additional legal information governing the use
+   Manager Agreement</a> " for additional legal information governing the
-  of the Eclipse update manager function.
+ use   of the Eclipse update manager function.
  <h3> <a name="Changes_from_R1.0"></a> Changes from R1.0</h3>
       This section describes the major design changes from the R1.0 Installation
    and Update support and supplies rationale for each design change.
  <ul>
       <li> <b>extendable framework</b></li>
        <br>
-Line 197
+Line 199
    <li>     <b>  feature support</b></li>
        <br>
      In R2.0 the concept of a <i>component</i> and <i>configuration</i> is
- merged  into <i>feature</i>. Features define the packaging structure for a
+  merged  into <i>feature</i>. Features define the packaging structure for
- group of related plug-ins, plug-in fragments, and optionally non-plug-in files.
+ a group of related plug-ins, plug-in fragments, and optionally non-plug-in
- Features are treated purely as an installation and packaging construct. They
+ files. Features are treated purely as an installation and packaging construct.
- do not play a role during Eclipse plug-in execution. Features do not nest.
+ They do not play a role during Eclipse plug-in execution. Features do not
- They are simply an inclusive "manifest" of the plug-ins, fragments and other
+ nest. They are simply an inclusive "manifest" of the plug-ins, fragments
- files that make up that feature. If features are logically made up of plug-ins
+ and other files that make up that feature. If features are logically made
- from "sub-features", the top-level feature "manifest" must be fully resolved
+ up of plug-ins from "sub-features", the top-level feature "manifest" must
- at packaging time. <li> <b>default feature archive format</b></li>
+ be fully resolved at packaging time. <li> <b>default feature archive format</b></li>
        <br>
      R1.0 components were packaged as a single Java .jar containing the component
    manifest as well as the actual plug-in files. The problem with this approach
-Line 215
+Line 217
    <b>site map</b></li>
        <br>
      Default Eclipse update server must contain a <i>site map</i> file (site.xml).
-   This is an evolution of the R1.0 install.index support. The rationale for
+    This is an evolution of the R1.0 install.index support. The rationale
-   using a structured site defined by the map rather than a "free form" web
+ for    using a structured site defined by the map rather than a "free form"
-  site, is the ability to present a consistent installation experience for
+ web   site, is the ability to present a consistent installation experience
- the user. Also, this provides the necessary structure for discovery of available
+ for  the user. Also, this provides the necessary structure for discovery
-  updates. Additional support for "free form" browsing may be considered in
+ of available   updates. Additional support for "free form" browsing may be
-  future work.    <li> <b>using native install/ uninstall</b></li>
+ considered in   future work.    <li> <b>using native install/ uninstall</b></li>
        <br>
      The primary mechanism for installing and updating Eclipse features is
- the  built-in installation and update support. Some products may instead choose
+  the  built-in installation and update support. Some products may instead
-  to use native installer technology (eg. MSI, RPM, etc) to deliver Eclipse
+ choose  to use native installer technology (eg. MSI, RPM, etc) to deliver
-  features. However, native installers do not implement the required support
+ Eclipse  features. However, native installers do not implement the required
-  for understanding the Eclipse installation structure. In particular, the
+ support  for understanding the Eclipse installation structure. In particular,
- native uninstallers will, by default, remove plug-in files that were installed
+ the native uninstallers will, by default, remove plug-in files that were
- using the native installer without regard to these plug-ins being needed
+ installed using the native installer without regard to these plug-ins being
- by other features. As a result, features installed using native installers
+ needed by other features. As a result, features installed using native installers
-  must be written into private product-specific installation location and
+  must be written into private product-specific installation location and not
- not  the shared Eclipse installation location. The shared Eclipse is made
+  the shared Eclipse installation location. The shared Eclipse is made aware
- aware  of the produce-specific location via an installed "link file". <li>
+  of the produce-specific location via an installed "link file". <li>
      <b>custom  install handling</b></li>
        <br>
      In many cases the standard installation handling supplied by Eclipse
  is  not be sufficient to handle various custom requirements. To accommodate
- this,  R2.0 Eclipse supports custom install handlers packaged as part of the
+  this,  R2.0 Eclipse supports custom install handlers packaged as part of
- feature  and executed during the feature installation. <li> <b>path naming
+ the feature  and executed during the feature installation. <li> <b>path naming
  conventions</b></li>
        <br>
      R1.0 mandated the use of the various identifiers and versions inside
-Line 247
+Line 249
   no longer mandate that path names of packaged files precisely reflect the
   contained identifiers and versions. The properly identified install subdirectories
   are created by the Eclipse support during the installation and update process
-   based on the archive content (rather than explicit jar path structure set
+    based on the archive content (rather than explicit jar path structure
-   up at packaging time)
+ set    up at packaging time)
  </ul>
  <h3> <a name="Concepts"></a> Concepts</h3>
       <b>Plug-in</b> <br>
      Eclipse developers build plug-ins. Plug-ins are the base units of execution
    recognized by the Eclipse runtime environment. In general, plug-ins are
- not exposed to users that select function during installation or update. The
+  not exposed to users that select function during installation or update.
- reason is that plug-in boundaries are established by developers for development
+ The reason is that plug-in boundaries are established by developers for development
    reasons (like function reuse) and present the wrong level of granularity
   in terms of what the user sees as the unit of function.
  <p>While plug-ins are being developed (ie. are frequently being changed),
-Line 264
+Line 266
    This will generally depend on the particular development tool being used.
    Typically, however, the developer will likely setup the plug-in to execute
    from a directory tree containing exposed .class files, rather than executing
-   from a .jar (requires an extra step to create the .jar and we all know developers
+    from a .jar (requires an extra step to create the .jar and we all know
-  hate extra steps). Also, at this stage the developer does not pay particular
+ developers  hate extra steps). Also, at this stage the developer does not
-  attention to plug-in versioning information, because the plug-in is continually
+ pay particular  attention to plug-in versioning information, because the
-  changing. </p>
+ plug-in is continually  changing. </p>
  <p>However, when the plug-in is ready to be packaged, it needs to be converted
-   to a form suitable for packaging and installation. Typically it means creation
+    to a form suitable for packaging and installation. Typically it means
-   of the runtime .jar(s) and removing any development-time files (source,
+ creation    of the runtime .jar(s) and removing any development-time files
- exposed .class files, etc). It also means updating the plugin.xml manifest
+ (source,  exposed .class files, etc). It also means updating the plugin.xml
- with the formal plug-in version and reflecting the version in the plug-in
+ manifest  with the formal plug-in version and reflecting the version in the
- directory name (see "Concurrent Plug-In Version Support" for details). </p>
+ plug-in  directory name (see "Concurrent Plug-In Version Support" for details).
+ </p>
  <p><b>Plug-in Fragment</b> <br>
-     Plug-in Fragments (or simply Fragments) allow independent packaging of
+      Plug-in Fragments (or simply Fragments) allow independent packaging
-  certain  aspects of the base plug-in. This includes (but may not be limited
+ of  certain  aspects of the base plug-in. This includes (but may not be limited
   to) translated  resources for the plug-in, OS-specific or windowing-system-specific
   code.  At runtime, fragments are logically merged into the base plug-in.
  From a packaging point of view, the install and update support does not really
-Line 287
+Line 290
  <p><b>Feature</b> <br>
      A feature is an installation packaging mechanism used to define a group
   of versioned plug-ins and/or plug-in fragments plus non-plug-in files that
-  is used to deliver some user function. A feature can also include other features.
+   is used to deliver some user function. A feature can also include other
-  Features are exposed to users as part of the packaging and installation
+ features.  Features are exposed to users as part of the packaging and installation
-  process,  because they represent a unit of function selection. Features
+  process,  because they represent a unit of function selection. Features also
- also  represent  a unit of installation. Features carry a version identifier.</p>
+  represent  a unit of installation. Features carry a version identifier.</p>
  <p>Features are packaged as a feature archive, referencing the required plug-ins,
-   plug-in fragments and optional non-plug-in files. The feature archives
+   plug-in fragments and optional non-plug-in files. The feature archives are
- are   placed on an update server for download and installation by the Eclipse
+   placed on an update server for download and installation by the Eclipse
  update  manager, or they can be used as the input into a formal packaging
  process  using one of the "traditional" installer technologies. The format
  of the feature archive is described later. </p>
  <h3> <a name="Framework"></a> Framework</h3>
-      The 2.0 installation and update support is provided as a framework that
+       The 2.0 installation and update support is provided as a framework
-  allows custom implementations to be supplied for its key elements. In particular,
+ that   allows custom implementations to be supplied for its key elements.
-   the following can be supplied:
+ In particular,    the following can be supplied:
  <ul>
-      <li> concrete implementations of feature (IFeature interface) that can
+       <li> concrete implementations of feature (IFeature interface) that
-  be used to support alternate packaging schemes. New concrete feature types
+ can   be used to support alternate packaging schemes. New concrete feature
-  are  registere via the "org.eclipse.update.featureTypes" extension point.</li>
+ types   are  registere via the "org.eclipse.update.featureTypes" extension
+ point.</li>
        <li> concrete implementations of site (ISite interface) that can be
  used  to support alternate site layout, or site behavior. New concrete site
- types   are registered via the "org.eclipse.update.siteTypes" extension point.</li>
+  types   are registered via the "org.eclipse.update.siteTypes" extension
-       <li> each feature can specify a custom install handler as part of its
+ point.</li>
-  feature  manifest. Install handlers (IInstallHandler interface) are dynamically
+        <li> each feature can specify a custom install handler as part of
-  invoked as part of the installation process to handle non-plugin data, plus
+ its   feature  manifest. Install handlers (IInstallHandler interface) are
-  perform other custom processing allowed by the framework.</li>
+ dynamically   invoked as part of the installation process to handle non-plugin
+ data, plus   perform other custom processing allowed by the framework.</li>
  </ul>
       Eclipse provides default implementations of feature and site. These
-Line 325
+Line 330
       <td><b>Note: <i>The reminder of this document describes the default
  concrete   implementation of the framework delivered with Eclipse. It specifies
  the  structure of the default feature implementation, as well as the default
- site  implementation, plus the corresponding xml files (feature.xml and site.xml).
+  site  implementation, plus the corresponding xml files (feature.xml and
-  Providers of alternate concrete implementations can extend&nbsp; parts or
+ site.xml).   Providers of alternate concrete implementations can extend&nbsp;
-  all of the default Eclipse implementation. This includes providing a mechanism
+ parts or   all of the default Eclipse implementation. This includes providing
-  for dynamic computation of the site map (site.xml)</i></b></td>
+ a mechanism   for dynamic computation of the site map (site.xml)</i></b></td>
       </tr>
    </tbody>
-Line 339
+Line 344
  <ul>
       <li> exactly one jar containing the feature manifest and related files.
    This one is refered to as the "<b>feature archive</b>"</li>
-       <li> zero or more jars containing the feature plug-ins. These are refered
+        <li> zero or more jars containing the feature plug-ins. These are
-   to as the "<b>plug-in archives</b>"</li>
+ refered   to as the "<b>plug-in archives</b>"</li>
        <li> zero or more non-plug-in files associated with the feature. They
   are used by feature custom install handlers and contain data not interpreted
    by Eclipse</li>
-Line 386
+Line 391
  <p><tt>&lt;?xml encoding="ISO-8859-1"?&gt;</tt> </p>
- <p><tt>&lt;!ELEMENT feature (install-handler?, description?, copyright?, license?,
+ <p><tt>&lt;!ELEMENT feature (install-handler?, description?, copyright?,
- url?, includes*, requires?, plugin*, data*)&gt;</tt> <br>
+ license?, url?, includes*, requires?, plugin*, data*)&gt;</tt> <br>
      <tt>&lt;!ATTLIST feature</tt> <br>
      <tt>&nbsp;&nbsp;&nbsp; id&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    CDATA #REQUIRED</tt> <br>
-Line 481
+Line 486
      <tt>&lt;!ATTLIST import</tt> <br>
      <tt>&nbsp;&nbsp;&nbsp; plugin&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
   CDATA #IMPLIED</tt><br>
-     <tt>&nbsp;&nbsp;&nbsp; feature &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CDATA #IMPLIED</tt><br>
+      <tt>&nbsp;&nbsp;&nbsp; feature &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CDATA
+ #IMPLIED</tt><br>
      <tt>&nbsp;&nbsp;&nbsp; version&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CDATA
    #IMPLIED</tt> <br>
      <tt>&nbsp;&nbsp;&nbsp; match&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
-Line 497
+Line 503
    CDATA #REQUIRED</tt> <br>
      <tt>&nbsp;&nbsp;&nbsp; version&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CDATA
    #REQUIRED</tt> <br>
-     <tt>&nbsp;&nbsp;&nbsp; fragment&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (true |
+      <tt>&nbsp;&nbsp;&nbsp; fragment&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (true
- false)  "false"</tt> <br>
+ |  false)  "false"</tt> <br>
      <tt>&nbsp;&nbsp;&nbsp; os&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    CDATA #IMPLIED</tt> <br>
      <tt>&nbsp;&nbsp;&nbsp; arch&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
-Line 544
+Line 550
   list  of os designators defined by Eclipse (see Javadoc for <tt>org.eclipse.core.boot.BootLoader)</tt>
    . Indicates this feature should only be installed on one of the specified
    os systems. If this attribute is not specified, the feature can be installed
-   on all systems (portable implementation). This information is used as a
+    on all systems (portable implementation). This information is used as
- hint by the installation and update support (user can force installation of
+ a  hint by the installation and update support (user can force installation
- feature regardless of this setting).</li>
+ of feature regardless of this setting).</li>
        <li> arch - optional machine architecture specification. A comma-separated
    list of architecture designators defined by Eclipse (see Javadoc for <tt>
    org.eclipse.core.boot.BootLoader)</tt>. Indicates this feature should only
-   be installed on one of the specified systems. If this attribute is not
+   be installed on one of the specified systems. If this attribute is not specified,
- specified,   the feature can be installed on all systems (portable implementation).
+   the feature can be installed on all systems (portable implementation). This
- This   information is used as a hint by the installation and update support
+   information is used as a hint by the installation and update support (user
- (user   can force installation of feature regardless of this setting).</li>
+   can force installation of feature regardless of this setting).</li>
        <li> ws - optional windowing system specification. A comma-separated
   list  of ws designators defined by Eclipse (see Javadoc for <tt>org.eclipse.core.boot.BootLoader)</tt>
    . Indicates this feature should only be installed on one of the specified
    ws systems. If this attribute is not specified, the feature can be installed
-   on all systems (portable implementation). This information is used as a
+    on all systems (portable implementation). This information is used as
- hint by the installation and update support (user can force installation of
+ a  hint by the installation and update support (user can force installation
- feature regardless of this setting).</li>
+ of feature regardless of this setting).</li>
        <li> nl - optional locale specification. A comma-separated list of
- locale   designators defined by Java. Indicates this feature should only
+ locale   designators defined by Java. Indicates this feature should only be
- be installed   on a system running with a compatible locale (using Java locale-matching
+ installed   on a system running with a compatible locale (using Java locale-matching
   rules). If this attribute is not specified, the feature can be installed
  on all systems (language-neutral implementation). This information is used
  as a hint by the installation and update support (user can force installation
-Line 576
+Line 582
        <li> primary - optional indication specifying whether this feature
  can   be used as a <a href="#Dominant_Feature">primary feature</a> . Default
  if        <i>false</i> (not a primary feature).</li>
-       <li> application - optional identifier of the Eclipse application that
+        <li> application - optional identifier of the Eclipse application
-   is to be used during startup when the declaring feature is the <a
+ that   is to be used during startup when the declaring feature is the <a
   href="#Dominant_Feature"> primary feature</a> . The application identifier
   must represent a valid application registered in the <tt>org.eclipse.core.runtime.applications</tt>
   extension point. Default is <tt>org.eclipse.ui.workbench</tt>.</li>
-Line 589
+Line 595
       <li> library - optional .jar library containing the install handler
  classes.   If specified, the referenced .jar must be contained in the feature
  archive.   It is specified as a path within the feature archive, relative
- to the feature.xml   entry. If not specified, the feature archive itself
+ to the feature.xml   entry. If not specified, the feature archive itself is
- is used to load the install handler classes. This attribute is only interpreted
+ used to load the install handler classes. This attribute is only interpreted
  if <i>class</i> attribute is also specified</li>
        <li> handler - optional identifier of the install handler. The value
-  is  interpreted depending on the value of the <i>library</i> attribute.
+  is  interpreted depending on the value of the <i>library</i> attribute. If
- If        <i>  library</i> is specified,&nbsp; the value is interpreted as
+        <i>  library</i> is specified,&nbsp; the value is interpreted as a
- a fully qualified  name of a class contained in the specified <i>library</i>.
+ fully qualified  name of a class contained in the specified <i>library</i>.
  If       <i>library</i>   is not specified, the value is is interpreted as
  an extension identifier  of an extension registered in the <i>org.eclipse.update.installHandlers</i>
     extension point. In either case, the resulting class must implement the
         <i> IInstallHandler</i> interface. The class is dynamically loaded
- and called at specific points during feature processing. The handler has visibility
+  and called at specific points during feature processing. The handler has
- to the API classes from the update plug-in, and Eclipse plug-ins required
+ visibility to the API classes from the update plug-in, and Eclipse plug-ins
- by the update plugin.</li>
+ required by the update plugin.</li>
    </ul>
        <li> &lt;description&gt; - brief component description as simple text.
-Line 610
+Line 616
    <ul>
       <li> url - optional URL for the full description as HTML. The URL can
-  be  specified as absolute of relative. If relative, it is assumed to be
+  be  specified as absolute of relative. If relative, it is assumed to be relative
- relative   to (and packaged in) the feature archive. Note, that for NL handling
+   to (and packaged in) the feature archive. Note, that for NL handling the
- the  URL value should be separated to allow alternate URLs to be specified
+  URL value should be separated to allow alternate URLs to be specified for
- for  each national language.</li>
+  each national language.</li>
    </ul>
        <li> &lt;copyright&gt; - feature copyright as simple text. Intended
-Line 621
+Line 627
    <ul>
       <li> url - optional URL for the full description as HTML. The URL can
-  be  specified as absolute of relative. If relative, it is assumed to be
+  be  specified as absolute of relative. If relative, it is assumed to be relative
- relative   to (and packaged in) the feature archive. Note, that for NL handling
+   to (and packaged in) the feature archive. Note, that for NL handling the
- the  URL value should be separated to allow alternate URLs to be specified
+  URL value should be separated to allow alternate URLs to be specified for
- for  each national language.</li>
+  each national language.</li>
    </ul>
        <li> &lt;license&gt; - feature "click-through" license as simple text.
    Intended to be translated. It is displayed in a standard dialog with [Accept]
-   [Reject] actions during the download/ installation process. Note, that
+   [Reject] actions during the download/ installation process. Note, that click-through
- click-through   license must be specified for any feature that will be selected
+   license must be specified for any feature that will be selected for installation
- for installation   or update using the Eclipse update manager. When using
+   or update using the Eclipse update manager. When using nested features,
- nested features, only the nesting parent (ie. the feature selected for installation
+ only the nesting parent (ie. the feature selected for installation or update)
- or update) must have click-through license text defined. The license text
+ must have click-through license text defined. The license text is required
- is required even if the optional <i>url</i> attribute is specified.</li>
+ even if the optional <i>url</i> attribute is specified.</li>
    <ul>
       <li> url - optional URL for the full description as HTML. The URL can
-  be  specified as absolute of relative. If relative, it is assumed to be
+  be  specified as absolute of relative. If relative, it is assumed to be relative
- relative   to (and packaged in) the feature archive. Note, that for NL handling
+   to (and packaged in) the feature archive. Note, that for NL handling the
- the  URL value should be separated to allow alternate URLs to be specified
+  URL value should be separated to allow alternate URLs to be specified for
- for  each national language. Note, that the "content" of this URL is <b>not</b>
+  each national language. Note, that the "content" of this URL is <b>not</b>
    what is presented as the click-through license during installation processing.
    The click-through license is the actual value of the <i>&lt;license&gt;</i>
     element (eg. <tt>&lt;license&gt;click through text&lt;/license&gt;</tt>)</li>
-Line 686
+Line 692
    the 2.0.1 behavior) requires that the feature has exactly the version specified
    by the version attribute. Other choices progressively relax the rule (<samp>
    equivalent</samp> allows only service part of the version to be more recent,
-         <samp>compatible</samp> also allows minor part to be included in
+         <samp>compatible</samp> also allows minor part to be included in the
- the   consideration, while <samp>greaterOrEqual</samp> simply allows any
+   consideration, while <samp>greaterOrEqual</samp> simply allows any version
- version   that is more recent or identical to the one specified).</li>
+   that is more recent or identical to the one specified).</li>
          <li>search_location&nbsp; - optional. Indicates whether the "New
  Updates"   action should search the update location determined by the nesting
  root feature  (<tt>root</tt>, is the default), or the location defined by
-Line 706
+Line 712
      <ul>
       <li> plugin - identifier of dependent plug-in.</li>
-           <li> feature - identifier of dependent feature. If plugin and feature
+            <li> feature - identifier of dependent feature. If plugin and
-   are specified, plugin takes precedence upon feature. Feature or plugin
+ feature   are specified, plugin takes precedence upon feature. Feature or
- must   be specified.</li>
+ plugin must   be specified.</li>
        <li> version - optional plug-in/feature version specification</li>
-           <li>patch - optional specification indicating if this feature is
+            <li>patch - optional specification indicating if this feature
-  a  patch of the dependant feature. Default is "false". If patch is true,
+ is  a  patch of the dependant feature. Default is "false". If patch is true,
  version  must be specified. If patch is true, only feature must be specified.
  If patch  is true, and match is specified, it must be 'perfect'.<br>
            </li>
-Line 726
+Line 732
              <li>if patch is true, and match is not specified, match defaults
    to perfect.<br>
              </li>
-       <li> <b><i>perfect</i></b> - dependent plug-in version must match exactly
+        <li> <b><i>perfect</i></b> - dependent plug-in version must match
-   the specified version.</li>
+ exactly   the specified version.</li>
-       <li> <b><i>equivalent</i></b> - dependent plug-in version must be at
+        <li> <b><i>equivalent</i></b> - dependent plug-in version must be
-  least  at the version specified, or at a higher service level (major and
+ at  least  at the version specified, or at a higher service level (major
- minor version  levels must equal the specified version).</li>
+ and minor version  levels must equal the specified version).</li>
-       <li> <b><i>compatible</i></b> - dependent plug-in version must be at
+        <li> <b><i>compatible</i></b> - dependent plug-in version must be
-  least  at the version specified, or at a higher service level or minor level
+ at  least  at the version specified, or at a higher service level or minor
-  (major  version level must equal the specified version).</li>
+ level  (major  version level must equal the specified version).</li>
        <li> <b><i>greaterOrEqual</i></b> - dependent plug-in version must
  be  at least at the version specified, or at a higher service, minor or major
   level.</li>
-Line 754
+Line 760
   list  of os designators defined by Eclipse (see Javadoc for <tt>org.eclipse.core.boot.BootLoader)</tt>
    . Indicates this entry should only be installed on one of the specified
  os  systems. If this attribute is not specified, the entry can be installed
-  on all systems (portable implementation). This information is used as a hint
+   on all systems (portable implementation). This information is used as a
-  by the installation and update support (user can force installation of entry
+ hint  by the installation and update support (user can force installation
-  regardless of this setting).</li>
+ of entry  regardless of this setting).</li>
        <li> arch - optional machine architecture specification. A comma-separated
    list of architecture designators defined by Eclipse (see Javadoc for <tt>
    org.eclipse.core.boot.BootLoader)</tt>. Indicates this feature should only
-   be installed on one of the specified systems. If this attribute is not
+   be installed on one of the specified systems. If this attribute is not specified,
- specified,   the feature can be installed on all systems (portable implementation).
+   the feature can be installed on all systems (portable implementation). This
- This   information is used as a hint by the installation and update support
+   information is used as a hint by the installation and update support (user
- (user   can force installation of feature regardless of this setting).</li>
+   can force installation of feature regardless of this setting).</li>
        <li> ws - optional windowing system specification. A comma-separated
   list  of ws designators defined by Eclipse (see Javadoc for <tt>org.eclipse.core.boot.BootLoader)</tt>
    . Indicates this entry should only be installed on one of the specified
  ws  systems. If this attribute is not specified, the entry can be installed
-  on all systems (portable implementation). This information is used as a hint
+   on all systems (portable implementation). This information is used as a
-  by the installation and update support (user can force installation of entry
+ hint  by the installation and update support (user can force installation
-  regardless of this setting).</li>
+ of entry  regardless of this setting).</li>
        <li> nl - optional locale specification. A comma-separated list of
  locale   designators defined by Java. Indicates this entry should only be
  installed   on a system running with a compatible locale (using Java locale-matching
   rules). If this attribute is not specified, the entry can be installed on
-  all systems (language-neutral implementation). This information is used
+  all systems (language-neutral implementation). This information is used as
- as  a hint by the installation and update support (user can force installation
+  a hint by the installation and update support (user can force installation
   of entry regardless of this setting).</li>
        <li> download-size - optional hint supplied by the feature packager,
   indicating  the download size in KBytes of the referenced plug-in archive.
-Line 788
+Line 794
  the implementation   needs to distinguish between "not known" and 0 size)</li>
    </ul>
-       <li> &lt;data&gt; - identifies non-plugin data that is part of the
+        <li> &lt;data&gt; - identifies non-plugin and non-feature data that
- feature</li>
+ is part of the feature. Generally, data are post-install processed using
+ feature Install handler. Feature files like feature.properties are not considered
+ data.</li>
    <ul>
       <li> id - required data identifier in the form of a relative path.</li>
-Line 797
+Line 805
   list  of os designators defined by Eclipse (see Javadoc for <tt>org.eclipse.core.boot.BootLoader)</tt>
    . Indicates this entry should only be installed on one of the specified
  os  systems. If this attribute is not specified, the entry can be installed
-  on all systems (portable implementation). This information is used as a hint
+   on all systems (portable implementation). This information is used as a
-  by the installation and update support (user can force installation of entry
+ hint  by the installation and update support (user can force installation
-  regardless of this setting).</li>
+ of entry  regardless of this setting).</li>
        <li> arch - optional machine architecture specification. A comma-separated
    list of architecture designators defined by Eclipse (see Javadoc for <tt>
    org.eclipse.core.boot.BootLoader)</tt>. Indicates this feature should only
-   be installed on one of the specified systems. If this attribute is not
+   be installed on one of the specified systems. If this attribute is not specified,
- specified,   the feature can be installed on all systems (portable implementation).
+   the feature can be installed on all systems (portable implementation). This
- This   information is used as a hint by the installation and update support
+   information is used as a hint by the installation and update support (user
- (user   can force installation of feature regardless of this setting).</li>
+   can force installation of feature regardless of this setting).</li>
        <li> ws - optional windowing system specification. A comma-separated
   list  of ws designators defined by Eclipse (see Javadoc for <tt>org.eclipse.core.boot.BootLoader)</tt>
    . Indicates this entry should only be installed on one of the specified
  ws  systems. If this attribute is not specified, the entry can be installed
-  on all systems (portable implementation). This information is used as a hint
+   on all systems (portable implementation). This information is used as a
-  by the installation and update support (user can force installation of entry
+ hint  by the installation and update support (user can force installation
-  regardless of this setting).</li>
+ of entry  regardless of this setting).</li>
        <li> nl - optional locale specification. A comma-separated list of
  locale   designators defined by Java. Indicates this entry should only be
  installed   on a system running with a compatible locale (using Java locale-matching
   rules). If this attribute is not specified, the entry can be installed on
-  all systems (language-neutral implementation). This information is used
+  all systems (language-neutral implementation). This information is used as
- as  a hint by the installation and update support (user can force installation
+  a hint by the installation and update support (user can force installation
   of entry regardless of this setting).</li>
        <li> download-size - optional hint supplied by the feature packager,
-  indicating  the download size in KBytes of the referenced data archive.
+  indicating  the download size in KBytes of the referenced data archive. If
- If  not specified,  the download size is not known (<b>Implementation Note:</b>
+  not specified,  the download size is not known (<b>Implementation Note:</b>
   the implementation  needs to distinguish between "not known" and 0 size)</li>
        <li> install-size - optional hint supplied by the feature packager,
- indicating   the install size in KBytes of the referenced data archive. If
+  indicating   the install size in KBytes of the referenced data archive.
- not specified,   the install size is not known (<b>Implementation Note:</b>
+ If  not specified,   the install size is not known (<b>Implementation Note:</b>
  the implementation   needs to distinguish between "not known" and 0 size)</li>
    </ul>
  </ul>
-      <a name="Feature_Archive_Mapping_Id_To_Path"></a> When interacting with
+       <a name="Feature_Archive_Mapping_Id_To_Path"></a> When interacting
-  the update site, the feature implementation maps the <tt>&lt;plugin&gt;</tt>
+ with   the update site, the feature implementation maps the <tt>&lt;plugin&gt;</tt>
   and <tt>&lt;data&gt;</tt> elements into path identifiers used by the site
   to determine the actual files to download and install. The default feature
   implementation supplied by Eclipse constructs the path identifiers as follows:
-Line 843
+Line 851
       <li> <tt>&lt;plugin&gt;</tt> element results in a path entry in the
  form   "<tt>plugins/&lt;pluginId&gt;_&lt;pluginVersion&gt;.jar</tt>" (for
  example,   "<tt>plugins/org.eclipse.core.boot_1.0.3.jar</tt>")</li>
-       <li> <tt>&lt;data&gt;</tt> element results in a path entry in the form
+        <li> <tt>&lt;data&gt;</tt> element results in a path entry in the
-   "<tt>features/&lt;featureId&gt;_&lt;featureVersion&gt;/&lt;dataId&gt;</tt>
+ form   "<tt>features/&lt;featureId&gt;_&lt;featureVersion&gt;/&lt;dataId&gt;</tt>
    " (for example, "f<tt>eatures/com.xyz.tools_2.3.1/examples.zip</tt>")</li>
  </ul>
-Line 853
+Line 861
  <p><tt>&lt;?xml version="1.0" encoding="UTF-8"?&gt;</tt> </p>
  <p>Translatable text contained in the feature.xml can be separated into feature&lt;_locale&gt;.properties
-   files using Java property bundle conventions. Note that the translated
+   files using Java property bundle conventions. Note that the translated strings
- strings   are used at installation time (ie. do not employ the plug-in fragment
+   are used at installation time (ie. do not employ the plug-in fragment runtime
- runtime   mechanism). </p>
+   mechanism). </p>
  <h3> <a name="Plug-In_Archive"></a> Plug-In Archive</h3>
       Plug-ins and plug-in fragments are individually packaged as separate
-Line 867
+Line 875
  <p>Where <tt>&lt;id&gt;</tt> is the plug-in or fragment identifier and <tt>
    &lt;version&gt;</tt> is the full version identifier contained in the respective
-   plugin.xml or fragment.xml. Note that this is a recommended convention
+   plugin.xml or fragment.xml. Note that this is a recommended convention that
- that   minimizes chance of collisions, but is not required by the Eclipse
+   minimizes chance of collisions, but is not required by the Eclipse architecture.
- architecture.   For example, the following are valid plug-in archive names
+   For example, the following are valid plug-in archive names </p>
- </p>
  <p><tt>org.eclipse.platform_1.0.3.jar</tt> <br>
      <tt>org.eclipse.ui.nl_2.0.jar</tt> <br>
      <tt>my_plugin.jar</tt> </p>
- <p>Internally, each plug-in archive packages all the relevant plug-in or fragment
+ <p>Internally, each plug-in archive packages all the relevant plug-in or
- files relative to its plug-in or fragment directory (but not including the
+ fragment files relative to its plug-in or fragment directory (but not including
- directory path element). The archive has the following structure </p>
+ the directory path element). The archive has the following structure </p>
  <p><tt>plugin.xml *OR* fragment.xml</tt> <br>
      <tt>other plug-in or feature files and subdirectories</tt> <br>
-Line 892
+Line 899
    to be added to the runtime without the need to repackage the base plug-ins.
  <p>This mechanism cannot be used for translating the actual packaging information
-   that is part of the installation xml files. Consequently the standard Java
+    that is part of the installation xml files. Consequently the standard
-   translation conventions are used for the packaging information, and all
+ Java    translation conventions are used for the packaging information, and
- necessary translations must be available at the time the feature is packaged.
+ all  necessary translations must be available at the time the feature is
- </p>
+ packaged.  </p>
  <h4> <a name="Translated_Feature_Information"></a> Translated Feature Information</h4>
       <b>Note:</b> This section describes the conventions used for translating
    the information contained within the feature manifest. It allows for the
-  update client to select the correctly localized strings from the update server.
+   update client to select the correctly localized strings from the update
-  This section specifically does not describe localization of individual plug-ins.
+ server.  This section specifically does not describe localization of individual
+ plug-ins.
  <p>Several of the attributes within the feature manifest are strings intended
-   for display through user interfaces. To facilitate translation, these attribute
+    for display through user interfaces. To facilitate translation, these
-   values use the convention defined for translatable attributes of plugin.xml.
+ attribute    values use the convention defined for translatable attributes
-   Strings beginning with % up to the first space are treated as resource identifier
+ of plugin.xml.    Strings beginning with % up to the first space are treated
-  keys (without the %) and looked up in a properties file. For example </p>
+ as resource identifier  keys (without the %) and looked up in a properties
+ file. For example </p>
  <p><tt>label="%cfg Tool Feature for Linux"</tt> </p>
  <p>results in a resource lookup in the correct property file with key "cfg".
-   If no property files are supplied, or the key is not found the default string
+    If no property files are supplied, or the key is not found the default
-  value (following the %key) is used. </p>
+ string  value (following the %key) is used. </p>
  <p>The property files are named as feature_&lt;locale&gt;.properties using
    the Java resource bundle naming conventions. Within the feature archive
-Line 948
+Line 956
       This topic is covered in separate documents available on the eclipse.org
    development resources page of the Update component.
  <h3> <a name="Packaging_Non_Plug_In_Files"></a> Packaging Non-Plug-In Files</h3>
-      Arbitrary non-plug-in files can be included as part of the feature definition
+       Arbitrary non-plug-in files can be included as part of the feature
-   using the <tt>&lt;data&gt;</tt> elements. Non-plug-in files typically also
+ definition    using the <tt>&lt;data&gt;</tt> elements. Non-plug-in files
-   requires specification of a custom install handler. In general, the Eclipse
+ typically also    requires specification of a custom install handler. In
-   support only downloads the referenced non-plug-in files and calls the custom
+ general, the Eclipse    support only downloads the referenced non-plug-in
-   install handler to perform any actual installation steps.
+ files and calls the custom    install handler to perform any actual installation
+ steps.
  <p>Eclipse does not specify the format of the non-plug-in files. </p>
  <h3> <a name="Custom_Install_Handling"></a> Custom Install Handling</h3>
-Line 963
+Line 972
   <tt>IInstallHandler</tt>). When required, the install handler is dynamically
   loaded by the installation and update code, and is called at specific points
   during its processing. The install handler code has visibility to classes
-  from the installation and update support plug-in, and its prerequisite plug-ins.
+   from the installation and update support plug-in, and its prerequisite
+ plug-ins.
- <p><b>Implementation Note:</b> the detailed list of visible prerequisite plug-ins
+ <p><b>Implementation Note:</b> the detailed list of visible prerequisite
- is still evolving. It is expected to include <tt>org.eclipse.core.boot </tt>
+ plug-ins is still evolving. It is expected to include <tt>org.eclipse.core.boot
- and <tt>org.eclipse.core.runtime</tt> in all cases, plus <tt>org.eclipse.ui</tt>
+ </tt> and <tt>org.eclipse.core.runtime</tt> in all cases, plus <tt>org.eclipse.ui</tt>
     and <tt>org.eclipse.swt</tt> when running with full workbench (ie. not
  "headless  mode"). Also, it would be useful to always expose <tt>org.eclipse.core.ant</tt>
     so that build scripts can be used as part of the install handler implementation.
    </p>
  <p>The IInstallHandler interface supports the following methods [<b>Implementation
-   Note:</b> the detailed definition of the IInstallHandler interface is still
+    Note:</b> the detailed definition of the IInstallHandler interface is
-   evolving. The description below is not an API specification (simply a functional
+ still    evolving. The description below is not an API specification (simply
-   description)]: </p>
+ a functional    description)]: </p>
  <ul>
       <li> install-initiated - the install handler is called after a feature
-  was selected for installation, but before any files were downloaded. It is
+   was selected for installation, but before any files were downloaded. It
-  intended  to implement any custom click-through or user registration dialogs.
+ is  intended  to implement any custom click-through or user registration
-  The base implementation of this method supplied with the abstract class
+ dialogs.  The base implementation of this method supplied with the abstract
-     <tt>BaseInstallHandler       </tt>performs the default click-through processing
+ class     <tt>BaseInstallHandler       </tt>performs the default click-through
- using the license  text supplied as part of the feature manifest. On return
+ processing using the license  text supplied as part of the feature manifest.
- this method indicates  success (installation continues) of failure (installation
+ On return this method indicates  success (installation continues) of failure
- is aborted).</li>
+ (installation is aborted).</li>
-       <li> install-downloaded - the install handler is called after all the
+        <li> install-downloaded - the install handler is called after all
-  required  feature files were downloaded (feature, plugins, data) but before
+ the   required  feature files were downloaded (feature, plugins, data) but
-  the actual  installation is performed. The install handler is expected to
+ before   the actual  installation is performed. The install handler is expected
-  perform verification  of the non-plug-in data files (eg. security), or any
+ to   perform verification  of the non-plug-in data files (eg. security),
-  other pre-install processing.&nbsp; On return this method indicates success
+ or any   other pre-install processing.&nbsp; On return this method indicates
-  (installation continues) or failure (installation is aborted).</li>
+ success   (installation continues) or failure (installation is aborted).</li>
-       <li> install-completion - the install handler is called after the feature
+        <li> install-completion - the install handler is called after the
-   information and the plug-ins were installed. It is expected to complete
+ feature   information and the plug-ins were installed. It is expected to
- the  installation of any non-plug-in data that was part of the feature. On
+ complete the  installation of any non-plug-in data that was part of the feature.
- return  this method indicates success (returns custom install log) or failure
+ On return  this method indicates success (returns custom install log) or
- (installation  is aborted). On failure, the install handler is expected to
+ failure (installation  is aborted). On failure, the install handler is expected
- perform any required cleanup.</li>
+ to perform any required cleanup.</li>
        <li> uninstall-initiated - the install handler is called when a feature
    is selected for removal, but before any of the standard uninstall processing
    has taken place. It is passed the custom install log created by the install
-Line 1034
+Line 1043
    </ul>
  </ul>
-      In general, when processing signed jars, the user will be prompted for
+       In general, when processing signed jars, the user will be prompted
-  each unrecognized certificate. The response choices will include aborting
+ for   each unrecognized certificate. The response choices will include aborting
   the installation (originator is not trusted), continuing the installation
   (originator is trusted for this installation).
  <h2> <a name="Update_Server"></a> Update Server</h2>
-Line 1047
+Line 1056
  <h3> <a name="Site_Map"></a> Site Map</h3>
       The update 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 file (similar
- to index.html   processing). The site map site.xml format is defined by the
+  to index.html   processing). The site map site.xml format is defined by
- following dtd:
+ the  following dtd:
  <p><tt>&lt;?xml encoding="ISO-8859-1"?&gt;</tt> </p>
  <p><tt>&lt;!ELEMENT site (description?, feature*, archive*, category-def*)&gt;</tt>
-Line 1076
+Line 1085
    #IMPLIED</tt> <br>
      <tt>&nbsp;&nbsp;&nbsp; url&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    CDATA #REQUIRED<br>
-    &nbsp;&nbsp;&nbsp; label &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; CDATA #IMPLIED<br>
+     &nbsp;&nbsp;&nbsp; label &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; CDATA
+ #IMPLIED<br>
    </tt><tt>&nbsp;&nbsp;&nbsp; os&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    CDATA #IMPLIED</tt> <br>
      <tt>&nbsp;&nbsp;&nbsp; arch&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
-Line 1137
+Line 1147
        <br>
      Note, that for NL handling the URL value should be separated to allow
  alternate  URLs to be specified for each national language.
    </ul>
        <li> &lt;feature&gt; - identifies referenced feature archive</li>
-Line 1147
+Line 1158
    feature type for the site. If the site type is the default Eclipse site
  type,  the default feature type is the packaged feature type (as specified
  in this  document).</li>
-       <li> id - optional feature identifier. The information is used as a
+        <li> id - optional feature identifier. The information is used as
- performance   optimization to speed up searches for features. Must match the
+ a  performance   optimization to speed up searches for features. Must match
- identifier   specified in the feature.xml of the referenced archive (the url
+ the identifier   specified in the feature.xml of the referenced archive (the
- attribute).   If specified, the version attribute must also be specified.</li>
+ url attribute).   If specified, the version attribute must also be specified.</li>
        <li> version - optional feature version. The information is used as
  a  performance  optimization to speed up searches for features. Must match
- the  version specified in the feature.xml of the referenced archive (the url
+  the  version specified in the feature.xml of the referenced archive (the
- attribute).  If specified, the id attribute must also be specified.</li>
+ url attribute).  If specified, the id attribute must also be specified.</li>
        <li> url - required URL reference to the feature archive. Can be relative
    or absolute. If relative, it is relative to the location of the site.xml
   file.       <b>Note</b>: the default site implementation allows features
- to be accessed without being explicitly declared using a &lt;feature&gt;
+ to be accessed without being explicitly declared using a &lt;feature&gt; entry.
- entry. By default, an undeclared features reference is interpreted as "features/&lt;id&gt;_&lt;version&gt;.jar"</li>
+ By default, an undeclared features reference is interpreted as "features/&lt;id&gt;_&lt;version&gt;.jar"</li>
         <li>label - optional feature label. The value is used for optimization
   when browsing the site from the update manager. Intended to be translated.<br>
        </li>
-Line 1181
+Line 1192
   list  of ws designators defined by Eclipse (see Javadoc for <tt>org.eclipse.core.boot.BootLoader)</tt>
    . Indicates this feature should only be installed on one of the specified
    ws systems. If this attribute&nbsp;is "*", the feature can be installed
-   on all systems (portable implementation). This information is used as a
+    on all systems (portable implementation). This information is used as
- hint by the installation and update support (user can force installation of
+ a  hint by the installation and update support (user can force installation
- feature regardless of this setting).</li>
+ of feature regardless of this setting).</li>
        <li> nl - optional locale specification. A comma-separated list of
- locale   designators defined by Java. Indicates this feature should only
+ locale   designators defined by Java. Indicates this feature should only be
- be installed   on a system running with a compatible locale (using Java locale-matching
+ installed   on a system running with a compatible locale (using Java locale-matching
   rules). If this attribute&nbsp;is "*", the feature can be installed on all
- systems (language-neutral implementation). This information is used as a hint
+  systems (language-neutral implementation). This information is used as a
- by the installation and update support (user can force installation of feature
+ hint by the installation and update support (user can force installation
- regardless of this setting).</li>
+ of feature regardless of this setting).</li>
        <li>patch - optional specification indicating if this feature is a
   patch. Default is "false".&nbsp;</li>
-Line 1199
+Line 1210
  actual  files referenced via the <tt>&lt;plugin&gt;</tt> or <tt>&lt;data&gt;</tt>
     elements in the feature manifest). The site simply manages archives as
  a  path-to-URL map. The default Eclipse site implementation does not require
-   the &lt;archive&gt; section to be included in the site map (site.xml).
+   the &lt;archive&gt; section to be included in the site map (site.xml). Any
- Any   archive reference not explicitly defined as part of an &lt;archive&gt;
+   archive reference not explicitly defined as part of an &lt;archive&gt; section
- section   is assumed to be mapped to a url in the form "&lt;archivePath&gt;"
+   is assumed to be mapped to a url in the form "&lt;archivePath&gt;" relative
- relative   to the location of the site.xml file.</li>
+   to the location of the site.xml file.</li>
    <ul>
       <li> path - required archive path identifier. This is a string that
  is  determined  by the <a href="#Feature_Archive_Mapping_Id_To_Path">feature</a>
-    referencing this archive and is not otherwise interpreted by the site
+    referencing this archive and is not otherwise interpreted by the site (other
- (other   than as a lookup token).</li>
+   than as a lookup token).</li>
-       <li> url - required URL reference to the archive. Can be relative or
+        <li> url - required URL reference to the archive. Can be relative
-  absolute.  If relative, it is relative to the location of the site.xml file.</li>
+ or  absolute.  If relative, it is relative to the location of the site.xml
+ file.</li>
    </ul>
        <li> &lt;category-def&gt; - an optional definition of a category that
-Line 1236
+Line 1248
  <p><tt>&lt;?xml version="1.0" encoding="UTF-8"?&gt;</tt> </p>
  <p>Translatable text contained in the site.xml can be separated into site&lt;_locale&gt;.properties
-   files using Java property bundle conventions. Note that the translated strings
+    files using Java property bundle conventions. Note that the translated
-  are used at installation time (ie. do not employ the plug-in fragment runtime
+ strings  are used at installation time (ie. do not employ the plug-in fragment
-  mechanism). The property bundles are located relative to the site.xml location.
+ runtime  mechanism). The property bundles are located relative to the site.xml
-   </p>
+ location.   </p>
  <h3> <a name="Default_Site_Layout"></a> Default Site Layout</h3>
       <tt>&lt;site root&gt;/</tt> <br>
-Line 1265
+Line 1277
    servlets that compute the site.xml map, and control access to individual
   archives based on some user criteria)</li>
        <li> by supplying a custom concrete implementation of the site object
-  (installed  on the client machine, update server specified <tt>&lt;site type=""&gt;</tt>
+   (installed  on the client machine, update server specified <tt>&lt;site
-  ). The custom concrete site implementation, together with any server-side
+ type=""&gt;</tt>  ). The custom concrete site implementation, together with
-   logic support the required control mechanisms.</li>
+ any server-side   logic support the required control mechanisms.</li>
  </ul>
       Eclipse provides an example demonstrating an implementation of an access
-Line 1298
+Line 1310
      <tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
   META_INF/</tt>   </p>
- <p><b>Implementation Note:</b> we will go back to the original design of not
+ <p><b>Implementation Note:</b> we will go back to the original design of
- splitting out fragments (ie. plugin and fragments go into the same install
+ not splitting out fragments (ie. plugin and fragments go into the same install
    location) </p>
  <h3> <a name="Unmanaged_Plugins"></a> "Unmanaged" Plug-Ins</h3>
       Eclipse supports a concept of "unmanaged" plug-ins. These are plug-ins
   that were directly installed into the Eclipse file tree without being part
-  of a feature (eg. developer unzipping plug-in archive directly into the Eclipse
+   of a feature (eg. developer unzipping plug-in archive directly into the
-  file tree).
+ Eclipse  file tree).
- <p>Eclipse runtime recognizes these plugins during startup and loads the plug-in
+ <p>Eclipse runtime recognizes these plugins during startup and loads the
- information into the runtime registry following the standard plug-in binding
+ plug-in information into the runtime registry following the standard plug-in
- rules. The update support also recognizes the presence of this new plug-in,
+ binding rules. The update support also recognizes the presence of this new
- but since this plug-in is not part of any feature it cannot be updated using
+ plug-in, but since this plug-in is not part of any feature it cannot be updated
- the update support (hence "unmanaged"). Unmanaged plug-in that become referenced
+ using the update support (hence "unmanaged"). Unmanaged plug-in that become
- by a feature as a result of some future installation or update action become
+ referenced by a feature as a result of some future installation or update
- "managed" (can be updated as part of the feature). </p>
+ action become "managed" (can be updated as part of the feature). </p>
  <p>Unmanaged plug-ins are not displayed as part of the installation and update
    UI. </p>
-Line 1321
+Line 1333
  <h3> <a name="Using_Native_Platform_Installers"></a> Using Native Platform
   Installers</h3>
       The Eclipse installation contains plugins that can be shared across
- multiple   features. When installing and uninstalling features using the
+ multiple   features. When installing and uninstalling features using the Eclipse
- Eclipse installation   and update support, these relationship are correctly
+ installation   and update support, these relationship are correctly maintained.
- maintained. Only one   copy of any version of a plug-in is used.
+ Only one   copy of any version of a plug-in is used.
  <p>However, when using native platform installers, performing native uninstall
    creates problems because plug-ins would be removed without regard to any
   sharing relationships. As a result, Eclipse <b>does not allow</b> plug-ins
   to be installed using native installers into the shared installation tree.
   Instead, native installers must establish their own installation root directory.
-  The subdirectory structure is the same as defined for base Eclipse. The private
+   The subdirectory structure is the same as defined for base Eclipse. The
-  root directory is logically linked into the shared Eclipse installation
+ private  root directory is logically linked into the shared Eclipse installation
   via  a link file installed by the native installer. The file path for the
   link  file is <tt>&lt;configRoot&gt;/links/</tt>. The <tt>&lt;configRoot&gt;
   </tt>  location is computed by Eclipse relative to the launch <a
-Line 1348
+Line 1360
  <p><tt>path=[r|rw] install-path[,[r|rw] install-path]*</tt> </p>
  <p>The property <tt>path</tt> is a comma-separated list of optionally annotated
-   install paths. The property value <tt>install-path</tt> is a full file path
+    install paths. The property value <tt>install-path</tt> is a full file
-  to the installation directory root, specified in local OS format. The optional
+ path  to the installation directory root, specified in local OS format. The
-  annotation <tt>r</tt> or <tt>rw</tt> indicates whether Eclipse update support
+ optional  annotation <tt>r</tt> or <tt>rw</tt> indicates whether Eclipse
-  should allow the specified location to be used for updates. Default is to
+ update support  should allow the specified location to be used for updates.
-  allow updates&nbsp; (w). </p>
+ Default is to  allow updates&nbsp; (w). </p>
  <p>Eclipse does not manage the linked directories in any way. It simply detects
    their existence by the presence of the link files, and includes the linked
    plug-ins during the platform startup. The native installer is responsible
-   for uninstalling the link when the corresponding directory is removed.
+   for uninstalling the link when the corresponding directory is removed. Eclipse
- Eclipse   runtime ignores any links that cannot be resolved. <br>
+   runtime ignores any links that cannot be resolved. <br>
      &nbsp; </p>
      <br>
     <br>
    <br>
   <br>
+  <br>
  </body>
  </html>

 Legend:



Removed from v.1.12
 


changed lines


 
Added in v.1.13
 Legend:



Removed from v.1.12
 


changed lines


 
Added in v.1.13
-Removed from v.1.12
+Added in v.1.13

help@eclipse.org	ViewVC Help
Powered by ViewVC 1.0.3