platform-update-home/doc/shared_eclipse_installs.html
Parent Directory
| 
Revision Log
Revision 1.2 -
(download)
(as text)
(annotate)
Fri Jun 21 19:01:42 2002 UTC (7 years, 5 months ago) by droberts
Branch: MAIN
CVS Tags: v20050526, R3_0, R3_1, v20040514, R2_0, v20040219, HEAD
Changes since 1.1: +1 -0 lines
Fri Jun 21 19:01:42 2002 UTC (7 years, 5 months ago) by droberts
Branch: MAIN
CVS Tags: v20050526, R3_0, R3_1, v20040514, R2_0, v20040219, HEAD
Changes since 1.1: +1 -0 lines
Add !DOCTYPE HTML 4.0 Transitional header
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Multi-user Installs of Eclipse-based Products</title>
</head>
<body>
<h1>Multi-user Installs of Eclipse-based Products</h1>
<p>Last revised 15:30 Monday May 6, 2002</p>
<p>There are special considerations when a product is installed somewhere in a
shared file system so that the installed base of files can be used
simultaneously by several users. Doing this requires making and maintaining a
clear separation between files containing information that should be common
across users from files containing user-specific information, for which each user will
need personal copies. It helps to think of the installed
based of files as being read-only (which they often are), and imagine that these
installed files can only be created or changed when the product is installed (or
updated). The user-specific files are stored elsewhere in some read-write user
space.</p>
<p>This note describes how shared, multi-user installs of Eclipse-based products work.</p>
<h2>What product developers need to know</h2>
<p>When an Eclipse-based product is installed on a disk, various files are laid
out in the product install directory (denoted <code><<i>install</i>></code>)
which is specified at the time the product is installed. Installed files
directly related to Eclipse are in the <code><<i>install</i>>/eclipse/</code>
subdirectory. Installed files are neither written nor deleted during the normal
course of operating the Eclipse-based product.</p>
<p>When an Eclipse-base product is installed, special one-time initialization is
initiated with the <code>-initialize</code> option. This invocation creates and
modifies files in <code><<i>install</i>>/eclipse/</code>. These files
ensure that the product starts quickly, with the correct splash screen, on
subsequent occasions. Once installed and initialized,
the <code><<i>install</i>></code> directory can be write-protected without
impacting the ability for a user to successfully operate the product stored
there. The product installer and the Eclipse update manager are the only parties
that alter the installed base of files. </p>
<p>Running an Eclipse-based product requires a read-write "workspace"
area (denoted <code><<i>workspace</i>></code>) to hold Eclipse platform
and plug-in data. The user can specify the location of the workspace area explicitly with <code>-data
<<i>workspace</i>></code> on the command line. If not specified on the
command line, the location of the workspace defaults to <code><<i>current
working directory</i>>/workspace/</code>. The user can have any number of
workspaces for use with a given product. Because of this, a single user with
several workspaces is the small scale version of a multi-user install; the only
significant difference is that in the former case the user is likely to also
have write access to the installed base of files.</p>
<p>To make things confusing, a common Windows shortcut to <code><<i>install</i>>/eclipse/eclipse.exe</code>
will default <code><<i>current working directory</i>></code> to the
directory holding the executable. As a direct consequence, the default workspace
will appear inside the install directory (!), at <code><<i>install</i>>/eclipse/workspace/</code>.
Similarly, a Windows shortcut to <code><<i>install</i>>/<i>myproduct</i>.exe</code>
will cause the default workspace to appear up one directory level, at <code><<i>install</i>>/workspace/</code>.
Both arrangements work fine for a single-user install, but are problematic for a
shared, multi-user install.</p>
<p>For a multi-user install, <code><<i>current working directory</i>></code>
should be a read-write directory in user space, apart from the <code><<i>install</i>></code>
directory. This ensures that the default workspace location is a different place
for each user. With a multi-user install, a user without write access to the install
directory would be unable to run the product installer or use the Eclipse update
manager to change the product install (however, it is still possible to use the
update manager to install and configure new features and product updates, just
not into the <code><<i>install</i>></code> directory).</p>
<h2>What product developers do not need to know</h2>
<p><b>N.B. The details in this section are not Eclipse platform API, and may
change over time. Do not rely on anything described in this section.</b></p>
<p>(0) Initial launch behavior</p>
<ul>
<li>done at install time</li>
<li>performs one-time initialization</li>
<li>optional, but highly recommended</li>
<li>done with <code>-initialize</code> option</li>
<li>runs headless</li>
<li>can use other options -data, -ws, -os, -nl, etc.</li>
<li>entails creating a scratch workspace somewhere (deleted on completion of install)</li>
<li>determines set of installed features and plug-ins</li>
<li>computes a maximal configuration using the most recent versions of all
features</li>
<li>unconditionally writes configuration info to <code><<i>install</i>>/eclipse/.config/platform.cfg</code></li>
<li> initial launch of a new workspace will be case (1)</li>
<li> <code><<i>install</i>>/eclipse/.config/platform.cfg</code> is used (only) on first user launches</li>
</ul>
<p>(1) New workspace - precomputed configuration in install (no <code><<i>workspace</i>>/.metadata/.config/platform.cfg</code>;
but <code><<i>install</i>>/eclipse/.config/platform.cfg</code> present)</p>
<ul>
<li>reads configuration <code><<i>install</i>>/eclipse/.config/platform.cfg</code>
</li>
<li>unconditionally writes configuration info to <code><<i>workspace</i>>/.metadata/.config/platform.cfg</code></li>
<li>this behavior ensures that workspace in not affected even if <code><<i>install</i>>/eclipse/.config/platform.cfg</code>
were to later change</li>
<li>happens once for each workspace</li>
</ul>
<p>(2) New workspace - no precomputed configuration in install (no <code><<i>workspace</i>>/.metadata/.config/platform.cfg</code>;
no <code><<i>install</i>>/eclipse/.config/platform.cfg</code> either)</p>
<ul>
<li>puts up simple splash screen saying "Completing the install. Please
wait..."</li>
<li>determines set of installed features and plug-ins</li>
<li>computes a maximal configuration using the most recent versions of all
features</li>
<li>unconditionally writes configuration info to <code><<i>workspace</i>>/.metadata/.config/platform.cfg</code></li>
<li>exit and relaunch</li>
</ul>
<p>(3) Existing workspace (<code><<i>workspace</i>>/.metadata/.config/platform.cfg</code>)</p>
<ul>
<li>reads configuration <code><<i>workspace</i>>/.metadata/.config/platform.cfg</code></li>
<li>may rewrite configuration info file</li>
</ul>
<p>Note that the above behavior is independent of whether the install is
single-user or multi-user.</p>
<p>Using Eclipse update manager to update an install</p>
<ul>
<li>allows privileged user to upgrade a multi-user install</li>
<li>allows user to upgrade a single-user install in a way that affects new
workspaces</li>
<li>user must have write access to <code><<i>install</i>></code></li>
<li>
<p ALIGN="LEFT">user launches eclipse with <code>-configuration
<install>/eclipse/.config/platform.cfg</code></li>
<li>installs new and updated features into <code><<i>install</i>>/eclipse/</code></li>
<li>creates new configurations in <code><<i>install</i>>/eclipse/.config/platform.cfg.metadata/</code></li>
<li>new configurations must only contain features and plug-ins within <code><<i>install</i>></code>
local site (or a local site linked to it)</li>
<li>sets default configuration by rewriting <code><<i>install</i>>/eclipse/.config/platform.cfg</code></li>
<li>deletes configurations from <code><<i>install</i>>/eclipse/.config/platform.cfg.metadata/</code></li>
<li>new configurations appear for all users</li>
<li>changes default configuration used for all new workspaces</li>
</ul>
<p>Using Eclipse update manager to update in the context of a single workspace</p>
<ul>
<li>user does not require write access to <code><<i>install</i>></code></li>
<li>
<p ALIGN="LEFT">user launches eclipse normally</li>
<li>installs new and updated features into any local site (possibly <code><<i>install</i>></code>)</li>
<li>creates new configurations in standard place (<code><<i>workspace</i>>/.metadata/.config/platform.cfg.metadata/</code>)</li>
<li>new configurations may contain features and plug-ins in any local
site </li>
<li>sets configuration for workspace by rewriting <code><<i>workspace</i>>/.metadata/.config/platform.cfg</code></li>
<li>sets configuration for workspace to default configuration for install</li>
<li>deletes configurations from <code><<i>workspace</i>>/.metadata/.config/platform.cfg.metadata/</code></li>
<li>features and configurations only appear when using <code><<i>workspace</i>></code></li>
</ul>
</body>
</html>
| help@eclipse.org | ViewVC Help |
| Powered by ViewVC 1.0.3 |