1. Background
Eclipse is a family of software products,
also known as a software product-line family.
An Eclipse product is organized into features or plugins. For example, the
standard Eclipse 3.0.1 installation contains 7 features, and 84 plugins.
This is reflected by the following physical directory structures:
eclipse_product\
features\
plugins\
Not all features and plugins are necessary for every user tasks, for example,
a C/C++ development user may want the CDT product, whereas the Java
developer does not need it. Therefore, we consider to create a script
to automatically install/uninstall any Eclipse product.
When the Eclipse platform starts, it first looks at its configuration directory
to see which features should be enabled, then every plugin needed in the
execution will be *lazily* loaded by the platform. Therefore,
the installation of an Eclipse product requires to copy the product features
and plugins into the Eclipse installation directory. The uninstallation of an
Eclipse product requires to remove the product features and plugins from the
Eclipse installation directory.
2. Problem
The installation/uninstallation may be a lengthy process involving
copying files.
3. Solution
In Unix system, one can ease it by creating logical
symbolic links of the product directories to the Eclipse platform
directory to alleviate the physically moving problem.
Symbolic links are not supported by Windows. Then
how to immitate the symbolic link mechanism
to achieve the fast installation/deinstallation on Windows?
In Eclipse, one can create a directory in the workspace
to mirror a directory in the file system. But the directories
in the Eclipse installation directory can not be created this way.
Our answer relies on the technique to
use the *junction* utility for the NTFS file system.
3.1 Junction point
In NTFS, a junction point is the information associated with a directory
that can be parsed by a system call. *junction* is a system utility provided
by the system internals web site, to use the junction point to record
information of a remote *real* directory such that the NTFS is "cheated"
to believe the directory is the remote directory. For example:
c:\> junction foo d:\foo
will create a mirror of the d:\foo as c:\foo. Here C: must be in a
NTFS file system, whereas D: can be any file system format.
Junction point is more powerful than the "subst" utility in the DOS file
system which mirrors a disk letter to a remote directory (I have
written a chapter on how to use *subst* utility to achieve symbolic
link effect some years ago). Here the remote directory is *mounted* to any
directory in the NTFS file system.
An important difference between a junction point and a symbolic link in
Unix, unfortunately, is that the junction point is treated as really
the remote directory. In other words, if one deletes the junction point
directory, all files under the remote directory will be removed.
To remove a junction point directory safely without removing the remote
files, the junction point is deleted by detaching it from the
remote directory. This can be done by the *junction* command by the "/d"
option:
c:\> junction /d foo
3.2 Scripting
The following is a Windows script to install the product to Eclipse
platform.
1 @echo off
2 set ECLIPSE=c:\eclipse
3 pushd %ECLIPSE%\features
4 for /D %%d in (%1\features\*) do @junction %%~nxd %%~dpnxd
5 cd ..\plugins
6 for /D %%d in (%1\plugins\*) do @junction %%~nxd %%~dpnxd
7 popd
First, let's assume the script has one argument that can be addressed
by %1 in the script. This argument is used as the directory of the
Eclipse product to be installed and the product has prepared a
*features* and a *plugins* subdirectory to hold the features and
plugins respectively.
Line 1 turns off the echoing of each following command in the script.
Line 2 assumes that the Eclipse platform is installed under C:\eclipse
directory.
Line 3 pushes the current directory in the directory stack, then change
the current directory to the Eclipse features directory.
Line 4 loops for every subdirectory (/D) to call the *junction* command.
The first argument given to the *junction* command is the filename and
extension name of the directory, the second argument is the full name
of the directory including its drive letter and full path.
Line 5 changes the current directory to the Eclipse plugins directory and
Line 6 calls the *junction* command in a similar matter as Line 4.
Finally, Line 7 changes the currenct directory back to the one popped from
the directory stack.
The following similar script uninstall the Eclipse product:
1 @echo off
2 set ECLIPSE=c:\eclipse
3 pushd %ECLIPSE%\features
4 for /D %%d in (%1\features\*) do @junction /d %%~nxd
5 cd ..\plugins
6 for /D %%d in (%1\plugins\*) do @junction /d %%~nxd
7 popd
3.3 Single button solution
Windows total commander is a shareware
inheriting most of the functionalities of a Norton commander. (It is one of my
favorite tool to play on Windows,
recommended by Prof. Erik H. D'Hollander.)
The tool is very easy to be customized. Here is how you can create a single
toolbar button to automate the above script.
1. Install the total commander, of course.
2. Press 1, 2 or 3 to the shareware question of Total commander to be
able to use all its functionality.
The file system is viewed by two parallel panes. The left-hand side shows
the Eclipse platform directory. The right-hand side shows the Eclipse product
directories, such as CDT (org.eclipse.cdt.sdk-3.0.0-M6-win32),
ecletex for latex,
ome4eclipse,
Lavadora webservice for Eclipse, etc. and also our scripts under the *eclipse-install* directory.
(I will write a separate tip on the usage of the latex plugins).
3. Now create a tool bar button by right click at the toolbar, apply *change...", fill in the following parameters:
Here %P%N indicate the Eclipse product directory that you just selected.
4. Place your mouse on one of the product directories, then press the
toolbar button. When you open the Eclispe plugin directories, you can see
the installed directories: the small shortcut decorator on the directory names
are created as junction point directories.
5. Alternatively, if you know which products to be installed before hand,
in the eclipse-install directory, prepare a script as follows:
call eclipse-install d:\ome4eclipse
call eclipse-install d:\org.eclipse.cdt.sdk-3.0.0-M6-win32
call eclipse-install d:\latex
call eclipse-install d:\webservice
Then doubleclick this script will install all products at once.
Resources
The scripts can be downloaded here.
December 7, 2005
The tutorial still works, but I found two simpler workarounds:
1) create a "links" subdirectory under the %ECLIPSE_HOME% directory.
For each product, create a file links/%product%.link which contains
a single line:
path=%path_to_product%
2) create an empty .eclipseextension file under the %product%/eclipse
directory, then use "Help/Manage configuration" dialog to add
an extension to the %product% directory
To me, the first alternative is better, since you may fully automate
the reconfiguration of Eclipse without using its dialog.
Note that the following technique may still be used to create a symbolic
link to the links directory because it is still under the Eclipse
SDK installation directory and could be removed along with the
Eclipse SDK.
Feb 28, 2005
The OpenOME project uses
this script to select the Eclipse products without physically copying them, on
the basis of the above finding.
August 1, 2006
Eclipse products can now be customized by a
downloading service that bundles them on the demand of a client.
September 15, 2006
One can perform automated update of Eclipse products at command line.
This is slower than the previous solution, but platform independent...
See how we update the OpenOME product and its dependent products
automatically for its users/developers.