| 1 |
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN2"> |
| 2 |
<html> |
<html> |
| 3 |
<head> |
<head> |
| 4 |
<title>Eclipse Update Site: Eating our own dog food</title> |
<title>Update Site Proposal</title> |
| 5 |
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> |
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"> |
| 6 |
<link rel="stylesheet" href="http://eclipse.org/default_style.css" type="text/css"> |
<meta http-equiv="Content-Style-Type" content="text/css"> |
| 7 |
|
<link href="http://dev.eclipse.org/default_style.css" rel="stylesheet" type="text/css"> |
| 8 |
</head> |
</head> |
| 9 |
|
<body bgcolor="#ffffff"> |
| 10 |
|
|
| 11 |
<body bgcolor="#FFFFFF" text="#000000"> |
<table width="100%"> |
| 12 |
|
<tr><td style="background:#0080C0"><b><span style="color:white">Proposal</span></b></td></tr> |
| 13 |
|
</table> |
| 14 |
<h1>Eclipse Update Site Proposal</h1> |
<h1>Eclipse Update Site Proposal</h1> |
| 15 |
<blockquote> |
<blockquote> |
| 16 |
<p><b>Summary</b> <br> |
<p><b>Summary</b> <br> |
| 24 |
configurations to meet all the demands. This proposal details a structure |
configurations to meet all the demands. This proposal details a structure |
| 25 |
which enables Eclipse component providers to contribute their features and |
which enables Eclipse component providers to contribute their features and |
| 26 |
plug-ins and for Eclipse consumers to efficiently select, download and install |
plug-ins and for Eclipse consumers to efficiently select, download and install |
| 27 |
their components of interest.<br> |
their components of interest.</p> |
| 28 |
Last Modified: 1100 February 17, 2004</p> |
<p> Last Modified: November 22, 2004</p> |
| 29 |
</blockquote> |
</blockquote> |
| 30 |
|
|
| 31 |
<h2>Problem Definition</h2> |
<h2>Problem Definition</h2> |
| 32 |
<p>The base Eclipse function is currently distributed as roughly the following |
<p>The base Eclipse function is currently distributed as roughly the following |
| 33 |
zip files</p> |
zip files (as of 3.1M3)</p> |
| 34 |
<ul> |
<ul> |
| 35 |
<li>binary Platform (one per target OS/WS) (7 x ~24MB)</li> |
<li>RCP Binary (one per target OS/WS) (8 x ~5MB)</li> |
| 36 |
<li>binary JDT (one OS/WS independent) (~12MB)</li> |
<li>RCP SDK (one per target OS/WS) (8 x ~18MB)</li> |
| 37 |
<li>SDK zips includind source and all doc (one per target OS/WS) (7 x ~80MB)</li> |
<li>Platform Binary (one per target OS/WS) (8 x ~25MB)</li> |
| 38 |
|
<li>Platform SDK (one per target OS/WS) (8 x ~56MB)</li> |
| 39 |
|
<li>JDT Binary (OS/WS independent) (~15MB)</li> |
| 40 |
|
<li>JDT SDK (OS/WS independent) (~27MB)</li> |
| 41 |
|
<li>PDE Binary (OS/WS independent) (~4MB)</li> |
| 42 |
|
<li>PDE SDK (OS/WS independent) (~5MB)</li> |
| 43 |
|
<li>Full Eclipse SDK zips including source and all doc (one per target OS/WS) |
| 44 |
|
(8 x ~88MB)</li> |
| 45 |
<li>assorted other zips (e.g., examples, webdav, ...)</li> |
<li>assorted other zips (e.g., examples, webdav, ...)</li> |
| 46 |
</ul> |
</ul> |
| 47 |
<p>Eclipse tools and technology project downloads are available separately and |
<p>Eclipse tools and technology project downloads are available separately and |
| 58 |
<p>The main issues with the current setup are:</p> |
<p>The main issues with the current setup are:</p> |
| 59 |
<ul> |
<ul> |
| 60 |
<li>Does not promote the easy provision, acquisition and use of plug-ins from |
<li>Does not promote the easy provision, acquisition and use of plug-ins from |
| 61 |
a variety of souces. The basic premise of Eclipse is that plug-in consumers |
a variety of sources. The basic premise of Eclipse is that plug-in consumers |
| 62 |
can gather a set of interesting plug-ins, put them together in an Eclipse platform |
|
| 63 |
configuration and enjoy an integrated seemless environment. Currently plug-in |
can gather a set of interesting plug-ins, put them together in an Eclipse |
| 64 |
|
platform configuration and enjoy an integrated seemless environment. Currently |
| 65 |
|
plug-in |
| 66 |
producers provide their plug-ins in various forms and the lack of any managed |
producers provide their plug-ins in various forms and the lack of any managed |
| 67 |
acquisition mechanism forces potential users to grovel around for plug-ins |
acquisition mechanism forces potential users to grovel around for plug-ins |
| 68 |
|
|
| 69 |
and then hope that they got the right thing.</li> |
and then hope that they got the right thing.</li> |
| 70 |
<li>Does not scale as the scope of Eclipse increases. The current approach addresses |
<li>Does not scale as the scope of Eclipse increases. The current approach addresses |
| 71 |
the provision/acquisition problem by packaging collections of interesting |
the provision/acquisition problem by packaging collections of interesting |
| 78 |
double the Eclipse SDK size). Following the current model, there would be |
double the Eclipse SDK size). Following the current model, there would be |
| 79 |
one of these uber-zips per target OS/WS.</li> |
one of these uber-zips per target OS/WS.</li> |
| 80 |
<li>Does not scale as the Eclipse use scenarios increase. As the range of people |
<li>Does not scale as the Eclipse use scenarios increase. As the range of people |
| 81 |
using Eclipse broadens, there will be increasing demand for alternative collections |
using Eclipse broadens, there will be increasing demand for alternative |
| 82 |
of plug-ins. These will contain either more or less than the Eclipse SDK. While |
collections |
| 83 |
we can take a stab and produce some common packagings, we will not</li> |
of plug-ins. These will contain either more or less than the Eclipse SDK. |
| 84 |
|
While we can take a stab and produce some common packagings, we are are |
| 85 |
|
not likely to satisfy all/most people.</li> |
| 86 |
<li>Makes poor use of existing disk and bandwidth resources. As mentioned earlier, |
<li>Makes poor use of existing disk and bandwidth resources. As mentioned earlier, |
| 87 |
something like 95% of each OS/WS specific SDK zip is identical content. Further, |
something like 95% of each OS/WS specific SDK zip is identical content. Further, |
| 88 |
from build to build, not all plug-ins change. The user doc for example tends |
from build to build, not all plug-ins change. The user doc for example tends |
| 94 |
and bandwidth for both eclipse.org and our users.</li> |
and bandwidth for both eclipse.org and our users.</li> |
| 95 |
<li>Finally, it is somewhat ironic that the update/install mechanism has been |
<li>Finally, it is somewhat ironic that the update/install mechanism has been |
| 96 |
designed in part to address exactly these kinds of concerns yet it is one |
designed in part to address exactly these kinds of concerns yet it is one |
| 97 |
|
|
| 98 |
of the few components that does not see regular use by the Eclipse team itself. |
of the few components that does not see regular use by the Eclipse team itself. |
| 99 |
As a result, the update/install team misses out on the regular feedback enjoyed |
As a result, the update/install team misses out on the regular feedback |
| 100 |
|
enjoyed |
| 101 |
by the other Eclipse teams. It is seemingly hard to justify putting update/install |
by the other Eclipse teams. It is seemingly hard to justify putting update/install |
| 102 |
forward as a useful technology but not using it ourselves. </li> |
forward as a useful technology while not using it ourselves. </li> |
| 103 |
</ul> |
</ul> |
| 104 |
<h2>Scenarios</h2> |
<h2>Scenarios</h2> |
| 105 |
<h3>Scenario 1: minimal install</h3> |
<h3>Scenario 1: minimal install</h3> |
| 155 |
<li>go to step 3 of scenario 1</li> |
<li>go to step 3 of scenario 1</li> |
| 156 |
</ol> |
</ol> |
| 157 |
<h2>Problem Solution</h2> |
<h2>Problem Solution</h2> |
| 158 |
We propose to use the Eclipse update technology to address the described problems |
<p>We propose to use the Eclipse update technology to address the described problems |
| 159 |
and implement the listed scenarios. Note that this new structure is a complement |
and implement the listed scenarios. Note that this new structure is a complement |
| 160 |
|
|
| 161 |
to the existing large zip packagings of Eclipse. We are not proposing to stop |
to the existing large zip packagings of Eclipse. We are not proposing to stop |
| 162 |
creating the familiar SDK etc zips. |
|
| 163 |
|
creating the familiar SDK etc zips. (we leave it to someone more brave to propose |
| 164 |
|
that!)</p> |
| 165 |
<h3>Update site</h3> |
<h3>Update site</h3> |
| 166 |
<p>eclipse.org (and others) will provide update sites sporting all the relevant |
<p>eclipse.org (and others) will provide update sites sporting all the relevant |
| 167 |
features and plug-ins. Collections of projects can cooperate and share an update |
features and plug-ins. Collections of projects can cooperate and share an update |
| 169 |
the need for some sort of shared site update mechanism. However, the user must |
the need for some sort of shared site update mechanism. However, the user must |
| 170 |
be able to navigate these individual sites seamlessly (see the section on Update |
be able to navigate these individual sites seamlessly (see the section on Update |
| 171 |
manager). </p> |
manager). </p> |
| 172 |
|
<p>There will be one update site per <em>release family</em>. A release family |
| 173 |
|
is a set of releases which form a substantial and separable effort. For example, |
| 174 |
|
Eclipse 2.0, 2.1, 3.0 and 3.1 are all different release families. The life |
| 175 |
|
of release family continues after its initial release (e.g., 3.0) to include |
| 176 |
|
maintenance releases (e.g., 3.0.1, 3.0.2, ...). Isolating release families |
| 177 |
|
to their own update sites helps maintain a separation between development going |
| 178 |
|
on for the next release family and maintenance work on the previous family.</p> |
| 179 |
<h3>Versioning</h3> |
<h3>Versioning</h3> |
| 180 |
<p>Update sites are not possible unless we use the Eclipse version numbering scheme |
<p>Update sites are not possible unless we use the Eclipse version numbering |
| 181 |
effectively. The main challenge is for plug-ins to have version numbers that |
scheme effectively. The main challenge is for plug-ins to have version numbers |
| 182 |
indicate their content. Updating versions so they correctly reflect semantic |
that |
| 183 |
change would be good but not essential. What is required however is that if |
accurately relate to their content. The essential element here is to ensure |
| 184 |
two plug-ins have the same id and version, their content is identical. The easiest |
that if two plug-ins have the same id and version, their content is identical. |
| 185 |
|
The |
| 186 |
|
easiest |
| 187 |
way to do this is to use the version qualifier (i.e., the forth version element). |
way to do this is to use the version qualifier (i.e., the forth version element). |
| 188 |
The qualifier should be the version tag from the map file used for the build |
For normal (not nightly) builds, the qualifier should be the version tag from |
| 189 |
which generated them (e.g., 3.0.0.v20040212). The map file defines the content |
the map file used for the build |
| 190 |
going into the build. If that does not change, then we can assume that the content |
which generated them (e.g., 3.1.0.v20041122). The map file defines the content |
| 191 |
of the output plug-in will not change. In this way, identical plug-ins will not |
going into the build. If that does not change, then we can assume that the |
| 192 |
be duplicated on the update site and consumers will not have to download them |
content |
| 193 |
if they already have them.</p> |
of the output plug-in will not change. In this way, identical plug-ins will |
| 194 |
<p>Features on the other hand are packagings of plug-ins. They are also relatively |
not be duplicated on the update site and consumers will not have to download |
| 195 |
small. Since the content of a feature is indirectly defined by the content of |
them |
| 196 |
the plug-ins included in the feature, it is hard to detect change. The safe bet |
if they already have them. For more detail on plugin versioning, see the <a href="http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-core-home/documents/plugin-versioning.html">Plug-in |
| 197 |
here is to use the build stamp as the qualifier for feature version (e.g., 3.0.0.I200402131200). |
Versioning Proposal</a>.</p> |
| 198 |
This has the benificial effect of clearly identifying the features for a particular |
<p>Features on the other hand are collections of plug-ins. They are also relatively |
| 199 |
|
small. Since the content of a feature is indirectly defined by the content |
| 200 |
|
of the plug-ins included in the feature, it is hard to detect change. The |
| 201 |
|
safe bet |
| 202 |
|
here is to use the build stamp as the qualifier for feature version (e.g., |
| 203 |
|
3.0.0.200402131200). This has the benificial effect of clearly identifying |
| 204 |
|
the features for a particular |
| 205 |
build. Further, since the entire feature set is regenerated, the collection |
build. Further, since the entire feature set is regenerated, the collection |
| 206 |
of features with the same version number completely defines the entire build |
of features with the same version number completely defines the entire build |
| 207 |
|
|
| 208 |
output.</p> |
output.</p> |
| 209 |
<p>Nightly builds would not go into the update site. There is no easy way to correlate |
<p>Nightly builds do not go into an update site. There is no easy way to correlate |
| 210 |
the content in a nightly build (out of HEAD) with that of an integration build |
the content in a nightly build (out of HEAD) with that of an integration build |
| 211 |
(using versioned resources). As a result, all plug-ins would be new and the economies |
|
| 212 |
of the proposed solution would not be realized. Further, nightly builds are |
(using versioned resources). As a result, all plug-ins would be new and the |
| 213 |
primarily there for the individual teams to ensure they have not adversely affected |
economies of the proposed solution would not be realized. Further, nightly |
| 214 |
other components etc. That is, they do not figure prominently in the scenarios |
builds are |
| 215 |
|
primarily there for the individual teams to ensure they have not adversely |
| 216 |
|
affected other components etc. That is, they do not figure prominently in |
| 217 |
|
the scenarios |
| 218 |
driving this proposal.</p> |
driving this proposal.</p> |
| 219 |
<p>Plug-in directories currently reflect the id and version of the plug-in. With |
<p>Plug-in directories currently reflect the id and version of the plug-in. With |
| 220 |
the addition of the map stamp, the directory names will grow by typically ~10 |
the addition of the map stamp, the directory names will grow by typically ~10 |
| 225 |
not interpreted. Qualifiers are compared using lexographical sorting. As such, |
not interpreted. Qualifiers are compared using lexographical sorting. As such, |
| 226 |
care should be |
care should be |
| 227 |
taken to ensure that the qualifier for subsequent builds monotonically increase. |
taken to ensure that the qualifier for subsequent builds monotonically increase. |
| 228 |
For example, rather than prepending the build type identifier (e.g., I20040217... |
For example, if a build type identifier is to be included in the qualifier, |
| 229 |
or M7), the build type should be appended and the build date used as the main |
it should be appended and |
| 230 |
body (e.g., 20040217-I and 20040213-M7).</p> |
the build date used |
| 231 |
<p></p> |
as the main |
| 232 |
<p></p> |
body (e.g., 20040217-I and 20040213-M7). See the complementary proposal on |
| 233 |
|
version numbering for more information.</p> |
| 234 |
<h3>Update manager</h3> |
<h3>Update manager</h3> |
| 235 |
<p>The main challenges for the update manager are in making all of this scale |
<p>The main challenges for the update manager are in making all of this scale |
| 236 |
and usable. </p> |
and usable. </p> |
| 310 |
</ul> |
</ul> |
| 311 |
<p>Note: the plugin.xml updating outlined above must be carried out on any manifest.mf |
<p>Note: the plugin.xml updating outlined above must be carried out on any manifest.mf |
| 312 |
files present in the build.</p> |
files present in the build.</p> |
|
<p></p> |
|
| 313 |
<p>PDE Build will also be updated to output directly to update site format. This |
<p>PDE Build will also be updated to output directly to update site format. This |
| 314 |
is already largely supported but there maybe some modest work required.</p> |
is already largely supported but there maybe some modest work required.</p> |
| 315 |
<p>A possible longer term advance is to change PDE build to only build the plug-ins |
<p>A possible longer term advance is to change PDE build to only build the plug-ins |
Parent Directory
| 
Revision Log
| 
Patch