Installing/uninstalling of an Eclipse product automatically -- created on June 7, 2005

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:
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, 
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.


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/ which contains
   a single line:
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.