platform-core-home/documents/update.html

Parent Directory | Revision Log | Patch

-revision 1.1, Tue Feb 17 16:34:54 2004 UTC
+revision 1.2, Wed Feb 18 18:30:02 2004 UTC
 Line 19
      is not feasible for eclipse.org to create, manage and distribute pre-packaged
      configurations to meet all the demands. This proposal details a structure
      which enables Eclipse component providers to contribute their features and
-     plugins and for Eclipse consumers to efficiently select, download and install
+     plug-ins and for Eclipse consumers to efficiently select, download and install
      their components of interest.<br>
      Last Modified: 1100 February 17, 2004</p>
  </blockquote>
 Line 39
    the single zip and go. If they need to run on two different platforms they download
    the zip for that platform and ignore the fact that 95% of the second download
    is the same as the first.</p>
- <p>Users looking to combine the base Eclipse with additional plugins/features
+ <p>Users looking to combine the base Eclipse with additional plug-ins/features
    are somewhat less happy. They have to search over several web sites, identifying
    downloads (zips) of interest and correlating versions manually. In general,
    the suppliers of these additional zips do not make it easy for users to understand
    their offerings.</p>
  <p>The main issues with the current setup are:</p>
  <ul>
-   <li>Does not promote the easy provision, acquisition and use of plugins from
+   <li>Does not promote the easy provision, acquisition and use of plug-ins from
-     a variety of souces. The basic premise of Eclipse is that plugin consumers
+     a variety of souces. The basic premise of Eclipse is that plug-in consumers
-     can gather a set of interesting plugins, put them together in an Eclipse platform
+     can gather a set of interesting plug-ins, put them together in an Eclipse platform
-     configuration and enjoy an integrated seemless environment. Currently plugin
+     configuration and enjoy an integrated seemless environment. Currently plug-in
-     producers provide their plugins in various forms and the lack of any managed
+     producers provide their plug-ins in various forms and the lack of any managed
-     acquisition mechanism forces potential users to grovel around for plugins
+     acquisition mechanism forces potential users to grovel around for plug-ins
      and then hope that they got the right thing.</li>
    <li>Does not scale as the scope of Eclipse increases. The current approach addresses
      the provision/acquisition problem by packaging collections of interesting
-     plugins together in a single zip. This works for Eclipse since it is at the
+     plug-ins together in a single zip. This works for Eclipse since it is at the
-     bottom of the plugin stack. However, others providers are not so lucky and
+     bottom of the plug-in stack. However, others providers are not so lucky and
      are challenged with questions like &quot;how many of my prerequisites should
-     I include in my download?&quot;. Further, as more and more plugins are added
+     I include in my download?&quot;. Further, as more and more plug-ins are added
      to the Eclipse world, the size of the complete zip increases. A zip of a reasonable
      set of SDK drops from projects on eclipse.org could easily reach 150MB (i.e.,
      double the Eclipse SDK size). Following the current model, there would be
      one of these uber-zips per target OS/WS.</li>
    <li>Does not scale as the Eclipse use scenarios increase. As the range of people
      using Eclipse broadens, there will be increasing demand for alternative collections
-     of plugins. These will contain either more or less than the Eclipse SDK. While
+     of plug-ins. These will contain either more or less than the Eclipse SDK. While
      we can take a stab and produce some common packagings, we will not</li>
    <li>Makes poor use of existing disk and bandwidth resources. As mentioned earlier,
      something like 95% of each OS/WS specific SDK zip is identical content. Further,
-     from build to build, not all plugins change. The user doc for example tends
+     from build to build, not all plug-ins change. The user doc for example tends
      to change slowly. Near the end of a milestone or release cycle we frequently
-     rebuild to fix isolated problems. Rather than rebuilding just the plugins
+     rebuild to fix isolated problems. Rather than rebuilding just the plug-ins
      in question and providing these for download, we rebuild the whole stack and
      repackage an entire set of full zips. Subsequently, interested developers
      are forced to redownload the bulk of what they already have. This wastes diskspace
 Line 105
  <p>After following the above scenario, the user can manage their configuration
    either using the steps outlined in Scenario 2 or by restarting their configuration
    with an indication that the update manager UI should be started. This puts them
-   back at step 3 but with all their previously installed plugins still installed.</p>
+   back at step 3 but with all their previously installed plug-ins still installed.</p>
  <h3>Scenario 2: building on a product install</h3>
  <p>In this scenario, the user has an Eclipse product installed (possibly just
    the Eclipse SDK from a downloaded zip file or the configuration from the steps
 Line 143
  creating the familiar SDK etc zips.
  <h3>Update site</h3>
  <p>eclipse.org (and others) will provide update sites sporting all the relevant
-   features and plugins. Collections of projects can cooperate and share an update
+   features and plug-ins. Collections of projects can cooperate and share an update
    site or each supply/support their own update site. Managing your own eliminates
    the need for some sort of shared site update mechanism. However, the user must
    be able to navigate these individual sites seamlessly (see the section on Update
    manager). </p>
  <h3>Versioning</h3>
  <p>Update sites are not possible unless we use the Eclipse version numbering scheme
-   effectively. The main challenge is for plugins to have version numbers that
+   effectively. The main challenge is for plug-ins to have version numbers that
    indicate their content. Updating versions so they correctly reflect semantic
    change would be good but not essential. What is required however is that if
-   two plugins have the same id and version, their content is identical. The easiest
+   two plug-ins have the same id and version, their content is identical. The easiest
    way to do this is to use the version qualifier (i.e., the forth version element).
    The qualifier should be the version tag from the map file used for the build
    which generated them (e.g., 3.0.0.v20040212). The map file defines the content
    going into the build. If that does not change, then we can assume that the content
-   of the output plugin will not change. In this way, identical plugins will not
+   of the output plug-in will not change. In this way, identical plug-ins will not
    be duplicated on the update site and consumers will not have to download them
    if they already have them.</p>
- <p>Features on the other hand are packagings of plugins. They are also relatively
+ <p>Features on the other hand are packagings of plug-ins. They are also relatively
    small. Since the content of a feature is indirectly defined by the content of
-   the plugins included in the feature, it is hard to detect change. The safe bet
+   the plug-ins included in the feature, it is hard to detect change. The safe bet
    here is to use the build stamp as the qualifier for feature version (e.g., 3.0.0.I200402131200).
    This has the benificial effect of clearly identifying the features for a particular
    build. Further, since the entire feature set is regenerated, the collection
 Line 171
    output.</p>
  <p>Nightly builds would not go into the update site. There is no easy way to correlate
    the content in a nightly build (out of HEAD) with that of an integration build
-   (using versioned resources). As a result, all plugins would be new and the economies
+   (using versioned resources). As a result, all plug-ins would be new and the economies
    of the proposed solution would not be realized. Further, nightly builds are
    primarily there for the individual teams to ensure they have not adversely affected
    other components etc. That is, they do not figure prominently in the scenarios
    driving this proposal.</p>
- <p>Plugin directories currently reflect the id and version of the plugin. With
+ <p>Plug-in directories currently reflect the id and version of the plug-in. With
    the addition of the map stamp, the directory names will grow by typically ~10
    chars). It is unlikely but this may push some path length limits. The use of
    the map stamp in a file/dir name may also place additional constraints the set
 Line 205
      list. They select their favourite root, click &quot;all required&quot; and
      get everything they need.</li>
    <li>the update manager mechanism may cache downloaded elements
-      (features and plugins) for use in future install operations. That is, if
+      (features and plug-ins) for use in future install operations. That is, if
-     you  already have the plugin/feature, you don't need to download it again.
+     you  already have the plug-in/feature, you don't need to download it again.
      The
      cache location should be (optionally) set by the user.</li>
    <li>ideally the update/install scenarios described will be possible when running
 Line 228
  </ul>
  <p>Interesting side note: using the runtime's new ability to run directly out
    of jars, it is possible to have many different eclipse configurations sharing
-   the same actual plugin files from the update manager's cache/store. This will
+   the same actual plug-in files from the update manager's cache/store. This will
-   break some assumptions about plugins being together in a plugins directory etc
+   break some assumptions about plug-ins being together in a plug-ins directory etc
    (the update reconciler may get upset) and it introduces some challenges for
    cache clean up but it is an interesting possibility.<br>
  </p>
  <h3>PDE Build</h3>
  <p>PDE Build already updates feature.xml files with the version numbers of the
-   plugins involved in the build. To support the version numbering scheme outlined
+   plug-ins involved in the build. To support the version numbering scheme outlined
    above, PDE Build will be updated to </p>
  <ul>
-   <li>modify the plugin version number in each plugin.xml (i.e., add the map stamp).
+   <li>modify the plug-in version number in each plugin.xml (i.e., add the map stamp).
      The version number of a plugin.xml is updated only if it contains &lt;_map
-     stamp_&gt; as the version qualifier. This allows plugins to opt out of this
+     stamp_&gt; as the version qualifier. This allows plug-ins to opt out of this
      update mechanism.</li>
    <li>modify the version number in the feature.xmls (i.e., add the build stamp).
      The version number of a feature.xml is updated only if it contains &lt;_map
      stamp_&gt; as the version qualifier. This allows features to opt out of this
      update mechanism. </li>
    <li>(advanced) modify the version number on &lt;import&gt; statements. Some
-     plugins and features may specify a perfect match rule in when listing their
+     plug-ins and features may specify a perfect match rule in when listing their
      dependencies. While this is not recommended, it is certainly possible. Unfortunately,
-     there is a conflict if the intention was that plugin A depend perfectly on
+     there is a conflict if the intention was that plug-in A depend perfectly on
-     the version of plugin B with which it was built. During the build, B's version
+     the version of plug-in B with which it was built. During the build, B's version
-     number will be updated according to its map stamp. Plugin A's &lt;import&gt;
+     number will be updated according to its map stamp. Plug-in A's &lt;import&gt;
      statement for B needs to be updated to reflect this new version. While this
      modification is technically possible, it requires more complex analysis of
-     the plugin.xml file. Updating the version of the plugin itself can be done
+     the plugin.xml file. Updating the version of the plug-in itself can be done
      using simple string replacement. In this case the builder has to
      <ul>
        <li>look at each &lt;import&gt; using perfect match and wanting build-time
 Line 272
  <p></p>
  <p>PDE Build will also be updated to output directly to update site format. This
    is already largely supported but there maybe some modest work required.</p>
- <p>A possible longer term advance is to change PDE build to only build the plugins
+ <p>A possible longer term advance is to change PDE build to only build the plug-ins
-   which actually changed. Since we know the map stamp of the plugins we want in
+   which actually changed. Since we know the map stamp of the plug-ins we want in
    the output, we can first look for those in the update site (or some cache).
    If present, there is no need to rebuild them. This will have a huge (positive)
    impact on rebuilds during release cycles.</p>
 Line 291
  <p>The key steps that should be taken for 3.0 are </p>
  <ul>
    <li>create/populate an update site</li>
-   <li>update PDE build to automate the stamping of plugins and features</li>
+   <li>update PDE build to automate the stamping of plug-ins and features</li>
    <li>a modest amount of work on update manager to enable reasonable workflows
      (i.e., set a stake in the ground)</li>
  </ul>

 Legend:



Removed from v.1.1
 


changed lines


 
Added in v.1.2
 Legend:



Removed from v.1.1
 


changed lines


 
Added in v.1.2
-Removed from v.1.1
+Added in v.1.2

help@eclipse.org	ViewVC Help
Powered by ViewVC 1.0.3