The previous version of the software update feature offered an option to install features and plug-ins in alternate directories. The current version doesn’t seem to have that option. Nevertheless, if you install plug-ins manually, you’re free to put them wherever you like.
If you do create an external directory for plug-ins, you have to let Eclipse know about it. On startup, Eclipse looks for a directory eclipse/links. In that directory create one or more text files whose names end in .link. Each file contains an entry of the form:
path=<path_to_eclipse plug-ins>
For example, path=/usr/local/eclipse-plugins
6.1.2 Updating Existing Features
The other thing the Update Manager can do is search for and install updates of existing features, including the platform itself. Select Help→Software Updates→Find and Install… but this time select Search for updates of the currently installed features. Click Finish and the Update Manager will search for updates to installed features. This can be a lengthy process, so you’ll probably want to click Run in Background so you can continue working while the update process runs.
The update search can be scheduled to run automatically. Select Window→Preferences…→Install/Update→Automatic Updates (Figure 6.4). Here you can choose from several update scheduling policies:
• No automatic update
• On every startup
• Every day at a specific time
• On a scheduled day of the week at a specific time
Figure 6.4: Scheduling automatic updates.
The last two options, of course, require that Eclipse is running at the selected time.
6.2 Target Management and the Remote System Explorer (RSE)
The Remote System Explorer (RSE) is a collection of tools that allows you to work with resources such as files and folders on remote systems. The Remote System Explorer perspective allows you to directly manipulate resources on a remote system. The available actions depend on the type of system you’re connecting to and the way the resource is recognized.
For a quick tour of some basic RSE capabilities, go to the Remote System Explorer perspective. Currently, there is one item called Local. This, in fact, is the local host.
Expand that item to reveal Local Files and Local Shells. Under Local Files is My Home and Root, which are fairly self-explanatory. Expand My Home, and you’ll see the contents of your home directory. Root, of course, is the entire local file system.
Right-click on Local Shells and select Launch Shell. This brings up a Remote Shell view in the lower tabbed window. Commands are entered in the small window at the bottom, and the results show up in the larger window. Figure 6.5 shows the result of executing the ls command on my workspace directory. File name completion is done with CTRL+Space rather than tab. The Remote Shell view has tool bar icons to clear the results, terminate the shell, and save both command results and command history to files.
Figure 6.5: Remote Shell.
6.2.1 Connecting to a Remote System
Of course, the Remote System Explorer isn’t very interesting until we connect to a remote system. This section assumes you have network access to another computer running Linux.
RSE is a framework that supports plugging in many different communication protocols. By default FTP and SSH (secure shell) are supported along with a more capable RSEspecific protocol called dstore. The latter requires a server running on the remote system. We’ll examine both SSH and dstore connections. SSH is easy, and requires fewer resources on the target; dstore has more functionality.
In the Remote Systems view, click the Define a connection icon or right-click on Local and select New→Connection…. The first step is to select the Remote System Type. Select SSH Only and click Next. The next screen (Figure 6.6) initially displays LOCALHOST as the Host name. Change that either to an IP address or to the name of a computer on your network. The Connection name defaults to the Host name, but you can change it to anything you want.
Figure 6.6: Setting up an SSH connection.
Clicking Next shows the file services available on the remote machine. Clicking Next again shows the available shell services. One final click on Next shows the available terminal services. Click Finish and the new connection shows up in the Remote Systems view. Incidentally, the SSH daemon must be running on the remote system. Most Linux distributions start it at boot time.
Expand the new connection to reveal entries similar to what we saw with Local. When you expand My Home or Root under Sftp Files, you’re required to enter a valid user ID and password for the remote system, which effectively logs you into it. You can now use copy and paste commands to move files between your local host and the remote system. Give it a try.
There’s an option to save the user ID and password as defaults, so you don’t have to enter them every time.
Right-click on Ssh Shells and select Launch Shell. You now have a command shell connected to the remote machine. You can also right-click any directory entry in the remote file system and launch a shell in that directory. This allows for multiple shells to the same remote system. These are opened as tabs in the Remote Shell view.
Right-click a text file in the remote system and select Open. The file is opened in the Eclipse editor.
The dstore protocol provides more capability than SSH at the expense of requiring a Java-based server running on the remote machine. dstore supports browsing into archive files such as tar, tgz, and zip. It supports remote search without transferring files to your local host. Nevertheless, the requirement for Java means it’s probably not the best fit for embedded devices.
Before creating a dstore connection, you must install the dstore server on the remote machine. Download it from the Target Management project download site at http://www.download.eclipse.org/dsdp/tm/downloads. Click on the latest release link, currently 3.0, and in that page scroll down to the DStore Server Runtime. Versions are available for Linux, Windows, other Unix, and Mac OS X (considered experimental). Currently, a server implementation for Windows CE is in “incubation.”
Decide where to install the server — on a Linux box /opt is a good place — and create a directory for it, say, /opt/rseserver. Untar the downloaded tar file there.
The dstore server also requires a Java Runtime Environment (JRE) version 1.4 or higher. An IBM, Sun, or equivalent JRE is required. The gcj-based jvm that comes with most Linux distributions doesn’t work. If necessary, refer back to Chapter 2, Installation, for information on installing a JRE. The scripts that start the Linux server also require Perl, which is installed by default on most distributions.
There are two ways to start the dstore server on a Linux remote system. As root user you can start a server daemon by executing the Perl script daemon.pl. The server daemon listens for connection requests on port 4075 by default. You can change the port number with an optional port argument to the script. In response to a connection request, the daemon spawns a dstore server.