Contents of my eclipse.ini:

	-showsplash
	org.eclipse.platform
	-vmargs
	-Dosgi.requiredJavaVersion=1.5
	-Xms256m
	-Xmx1024m
	-XX:PermSize=64M
	-XX:MaxPermSize=256M

The Eclipse workspace is a concept that allows you to collect related projects into one space. You don't have to keep all your projects, however unrelated, in one place. (You can also use "working sets" to solve this and similar problems, but I despise large numbers of projects in my workspace.)

Workspaces are less of a headache than you might think. For example, if you don't like the name of a workspace, you might simply rename it in the file system. The next time you launch Eclipse, you can navigate to it and choose it. You can even swap names thus:

	russ@taliesin:~/dev> mv workspace-2.0 poop
	russ@taliesin:~/dev> mv workspace-1.8 workspace-2.0
	russ@taliesin:~/dev> mv poop workspace-futures

One annoying thing about Eclipse is that it doesn't display the name of the current workspace anywhere. You must determine this by process of elimination: go to File->Switch Workspace. If the workspace you think you're presently working in isn't listed, then that's probably the one you are working in.

In the case where a different (for example, more modern) JDK/JRE and/or Tomcat were used inadvertantly, it becomes difficult to change them back. The simplest way is to delete the project, but not its source code which is sitting in the filesystem from Subversion, or created and already existing and which we don't want to use, and recreate it.

You should have used the 1.4 JDK.

After deleting the project, drop the Eclipse workbench. Go to the filesystem and remove the following files and subdirectory:

• .project
• .classpath
• .settings
• build

Do not remove subdirectory build if it is actually part of your source code (which should not, but could be the case if you chose it on purpose—it is the name Eclipse chooses to call the place it puts built classes, but in our case here, we always change this to classes either under web/WEB-INFO or directly under the project.

To compare your code with what you got out from the repository or what has been committed since, right-click on the source file name in the Package Explorer, click on Compare With, then choose one of Base Revision, shows what changes you have made or Latest from Repository, shows how different from latest check-in which may have happened after you began modifying code.

There are still other options there.

Someone else just committed changes to code since you performed your last commit. How to see those? Right-click on the file, choose Team and then Show History. Go to the History window that should have opened in a pane somewhere in the workbench. Click on the latest version (at the top of the list) and control-click on the version you last worked on. Then, right-click on one of the selected versions and choose Compare. This gives you the same side-by-side comparison as the first method noted in this section.

Any two versions may be compared in this manner; just control-click the two that interest you.

When you run a stand-alone Java program, its current working directory is simply where it was launched from. That's expected. However, what about running a class in Eclipse when right-clicking and choosing Run As->Java application? The current working directory is <workspace/project>. You can prove it to yourself using this code fragment:

	String  cwd = System.getProperty(  "user.dir" );
	System.out.println( "Current working directory: " + cwd );

I can only endure seeing a misspelling so long before I want to tell a spell-checker to stop bothering me with it. Red-underlined variable names don't bother me in comments (au contraire, in fact), but perfectly good words like my own name, downloaded, idempotent, credentials and programmatically, to mention but a few, are really annoying to see comment after comment, file after file.

I'm running Europa (3.3.2). I followed the procedure here. As I had no user dictionary to begin with, I had to create one as described here too.

1. Opened a shell to my Eclipse installation directory, /home/russ/dev/eclipse-europa
2. Typed touch user-dictionary
3. Edited Eclipse Preferences:
   - Window->Preferences...->General->Editors->Text Editors->Spelling
   - Browse to (empty) user-dictionary (created in step 2)
4. Choose Apply in preferences dialog

1. Click on the word (e.g.: idempotent) and type CTRL-1
2. Click on Add 'idempotent' to dictionary

To stop seeing the word underlined in the editor in other files, you must close the file and reopen it.

To remove a term mistakenly added, use Vi[m] to edit user-dictionary and delete the word (and its line).

This comes out as the name of the (Linux) user. To change this, create a Launcher shortcut and type the Launcher->Command as

	/home/russ/dev/eclipse/europa/eclipse -vmargs -Duser.name="Russell Bateman"

Note: “user.name” is a Java property.

Sometimes control-clicking in the editor or single-stepping down through code, code for which the source is unknown to Eclipse is encountered. An edit window comes up with...

	Class File Editor

	Source not found
	_____________________________________________________________________________
	The jar file XxxxxYyyyy.jar has no source attachment.
	You can attach the source by clicking Attach Source below:

	[Button: Attach Source]

To remedy this, click the Attach Source button to get the Source Attachment Configuration dialog. There, you click on one of three buttons to attach the source.

However, you are not really attaching source code (by .java extension), but looking for code associated with the JAR in question.

Source code and JARs

Some JARs come with source code and many do not. You have to pay attention to get the source code to, say, the Apache HTTP client code, otherwise you end up with only the binary JAR you need to link with. This is not usually a problem because you can consider that the supplier has done his job perfectly and if there's an error or bug, it's your own and usually you can determine the defugalty by your own means without that third-party source code.

(This foregoing discussion is incomplete because I'm not elaborating on where or how to get the source code to third-party JARs even though I've done it before. Maybe another time when I have to do it again.)

When adding JARs to the build path via right-clicking on a project, choosing Build Path->Configure Build Path..., and then clicking on Libraries, you can see, if you click to open a listed xxx.jar, Source attachment:. Clicking, you'll see you can Edit... the path: you fall into the same sequence as described for the Editor above.

Javadoc and JARs

This is a similar discussion as the preceding one for source attachments in Build Path. Edit the path to Javadoc location:. Instead of navigating to the project, you'll be looking for an index.html in the distribution. Choose its parent directory.

Making new jars and supplying to other projects...

In a mixed environment of one workspace with multiple, interdependent projects, the JAR of one project must be ported to the web/WEB-INF/lib of another. This is usually done by an ant script, but as I'm working in Linux and have slightly different path assumptions, the existing scripts won't do it for me.

How has this been working? It has worked because I have not so far modified shared code (code outside RetainServer in fact) and when such code is modified, it eventually finds its way into the repository and my updating gets it from there.

How to do this...

1. Do Window->Show View...->ant
2. Click on the Add Buildfiles icon
3. Find the shared project needing rebuild (SharedJava for example).
4. Open the triangle and click on ant.xml.
5. Click OK to add it: something should show up in the Ant Pane.
6. Open MNShared.
   

   These are all little ant scripts to do precious things like clean up, copy the trunk, etc. including make a jar. Double-clicking on any script runs the script. (The clean script is a good one to run.)

   Watch the console window to see what this does when you run a script.

   If you make a new JAR, it will put it in a (usually) harmless place. You can copy it from there on the needed path (/home/russ/dev/svn/source-code/web/WEB-INF/lib).

When suddenly everything is full of red stop signs and the whole damn compilation state seems to come crashing down, there is a sequence of panic instructions. Before pointing a small, handheld firearm at your temple, try the following—maybe in this order:

1. Bounce Eclipse.
2. Refresh each individual project (right-click on project, choose Refresh).
3. Update (right-click on project, choose Team->Update).
4. Clean and rebuild—probably happening automatically, but if not (click the Project menu, choose Clean..., then Clean all projects, then click OK).
5. Close a project. If you have more than one project open, try closing several (to reduce the number of errors distracting you) and then concentrate on figuring out where the errors come from. This should be done intelligently; if projects interdepend rather than operate off each other via ant-built JARs or something, then narrow it down to the most fundamental and least dependent project, of course. To close a project, right-click on the project and choose Close Project.

Imagine you've just done an svn update, but the build is broken. Someone changed from using one third-party library version (in other words, a library not beloning to or build as a project) to a later one, but Eclipse says in the Problem pane that it's still looking for the older one. Everywhere else, (Build Path->Configure Build Path->Libraries->Web App Libraries), it says the new version of the library. In the project gating this third-party library in (so each project doesn't do it separately), it says the new version. In the file system, what came down from svn says the later version.

Eclipse may have a bug here. What may fix it is to remove the Web App Library and readd it from the supplying project.

I observe that every time one of the other team members changes a JAR on the path RetainServer/web/WEB-INF/lib, this is the result on Linux and not on Eclipse running under Windows. The solution is always to remove Web App Libraries and use the Add Library wizard to add it all over again.

Of course, never add any JAR files by hand when you're trying to get them from sibling projects in Eclipse. There's no end to trouble there.

Imagine you've just done an svn update, but the build is broken. Someone replaced a third-party library with another, but Eclipse says in the Problem view that it's still looking for the older name.

The problem is that Eclipse will not tell you why it is requiring a library that no longer exists anywhere. The challenge is to find its record of that library and expunge it.

Go to the projects reported in Problems as missing the required library (under the old name), right-click and choose Build Paths, then Libraries tab and search for the JAR by its old name. If you find it, simply click Remove.

That failing, the problem lies in the "furnishing" project (often RetainServer in my case).

Second, it's a problem that Eclipse doesn't yet know of the new library, which must exist. The first thing to expect is failure to commit on the part of your colleague who renamed it. Ensure this is the case by updating then checking the svn filesystem area.

Ultimately, it may be the old Refresh versus relaunch Eclipse thing. After failing to clear the problem with one of the two steps, try the other.

Don't forget that if you're consuming a collective library from one project in (one or more) others, you may have built that library wrong. Invoke the ant script for the supplying project to clean, compile and copy the JAR to the other projects. Then, commit the JAR in those projects requiring it.

This can happen easily if you're working in the supplying project and do the ant build with your new stuff without updating and getting what everyone else has done new in that project since last update. You're pushing a new, incomplete or inaccurate JAR out to the other projects, even after update, and then trying to build.

To avoid this trap, never commit JARs until you have done a full update and build. If you're trying things out locally, don't update any other projects (risking getting new stuff) until you've finished experimenting.

Granted, this explanation isn't as clear as it could be.

If another on your project has added a new JAR to be consumed, it must be added by hand in Eclipse. I don't understand why there would not be some way of communicating to Eclipse that this has happened, but developers cooperating on a project in Eclipse must still knit their projects together on an on-going basis with no help from the IDE.

Open the Build Path dialog, click on Libraries, then Add JARS.... Find the new JAR and add it.

...since its build path is incomplete. Cannot find the class file for java.lang.Enum.

This little infuriating gem is caused by not having the right run-time. Just because you have Java 5 in your Java Compiler setting doesn't mean that Build Paths->Libraries will follow.

Remove the JRE System Library [j2sdk1.4.2_18] or similar Java Runtime Environment library and add the correct one to match your Java 5 set-up: Add Library...->JRE System Library->Next->Alternate JRE:-> then choose, for example, jdk1.5.0_17 and Finish.

Other, specific errors about Enums will go away when you do this.

It's possible to tell Eclipse to perform certain tasks each time it rebuilds a project. For example, you might want to create an ant script.

To set up an ant script to fire when Eclipse builds...

1. Right-click on the project and choose Properties.
2. Click on Builders.
3. Click on New....
4. Choose Ant Builder (if an ant script is what you created.
5. Give the builder a name, choose the path to the build file (i.e.: the ant script), the base directory*, and arguments.

* base directory refers to the project attribute in the ant script, e.g.:

	<project name="Retain" basedir="." default="main">

Obviously, if the task takes a long time, you have to rethink whether this is really what you want to do or not.

I have to bounce it several times per day. Here's how.

	russ@taliesin:~> eclipse?
	Europa instances running:
	russ   16431   1  0 Jun01 ?   00:05:31 /home/russ/dev/eclipse-europa/eclipse -os linux \
	-ws gtk -arch x86 \
	-showsplash /home/russ/dev/eclipse-europa//plugins/org.eclipse.platform_3.3.3.r33x_r20080129/splash.bmp \
	-launcher /home/russ/dev/eclipse-europa/eclipse -name Eclipse \
	--launcher.library /home/russ/dev/eclipse-europa/plugins/org.eclipse.equinox.launcher.gtk.linux.\
	   x86_1.0.3.R33x_v20080118/eclipse_1023.so \
	-startup /home/russ/dev/eclipse-europa/plugins/org.eclipse.equinox.launcher_1.0.1.R33x_v20080118.jar \
	-launcher /home/russ/dev/eclipse-europa/eclipse -launcher /home/russ/dev/eclipse-europa/eclipse \
	-data /home/russ/dev/workspace-2.0 -launcher /home/russ/dev/eclipse-europa/eclipse \
	-vm /usr/lib/jvm/java-1.6.0-sun-1.6.0/jre/lib/i386/client/libjvm.so -vmargs -Duser.name=Russell Bateman

	  1 instance: pid to kill is 16431, kill it? [y/n]: y
	kill -9 16431

The script I use, kill-eclipse.sh aliased to command eclipse? is

	#!/bin/sh
	# This script ascertains whether there are any instances of Eclipse running
	# and, if so, lists them. If there is only one, it offers to kill it for you.
	echo "Europa instances running:"
	ps -ef | grep [e]clipse-europa
	echo

	count=`ps -ef | grep [e]clipse-europa | wc | awk '{ print $1 }'`
	  pid=`ps -ef | grep [e]clipse-europa      | awk '{ print $2 }'`

	if [ $count -eq 0 ]; then
	  echo "  No instances to kill, quitting..."
	  exit 0
	elif [ $count -eq 1 ]; then
	  echo -n "  $count instance: pid to kill is $pid, kill it? [y/n]: "
	  read ans
	  if [ "$ans" = "y" -o "$ans" = "Y" ]; then
	    echo "kill -9 $pid"
	    kill -9 $pid
	  fi
	else
	  echo "  $count instances to kill: you decide which one."
	fi
	echo

	# vim: set tabstop=2 shiftwidth=2 noexpandtab:

If you want to delete a project and start over, you must clean up the file system or trying to recreate the project by the same name will get you an error to the effect that a project of that name already exists.

The filesystem will be cleaned up if you delete the project sources too, but that would not normally be the case. Instead, you keep the sources (presumably on a path separate from the workspace, maybe a filesystem created by svn, and you must clean up a number of configuration files from the root of the project sources.

	# rm .project
	# rm .classpath
	# rm -rf .settings

I run openSuSE 10.3 using GNOME, using two Dell 24" wide-aspect monitors. Whatever the reason, backgrounds such as this page uses are washed out and scarcely visible. I've tried adjusting the contrast and brightness settings, but nothing seems to work. Otherwise, I love the environment and my monitors.

What this affects mostly for me is my ability to see editor annotations, that is, little rectangles in the margin at the right of the Editor Panel. While the error annoations (meaning, "error at this line—click here") are always perfectly visible, and the warning annotations are visible enough, others aren't and some of them are actually very useful.

To change the color associated with a particular annotation, go to Window->Preferences->General->Editors->Text Editors->Annotations. Select the invisible annotation, Occurrences for instance, and then click the Color: control to change it to something visible.

The right margin is formally called the Overview ruler. It's the left margin that is referred to as the Vertical ruler.

Here's some advice on build paths off a forum.

There are three different classpaths to be aware of when you are running Eclipse. First, Eclipse itself is a Java application, so it has a classpath; mostly you don't care about this one, except to make sure you're not confusing it with the others. Second, there is the classpath (referred to as the Java Build Path) that is in effect when you compile your code. This affects what classes are visible—for instance, if your code contains a reference to a class named Foo, then there must be a project or a jar file containing Fooon your project's build path. Third, there is the classpath that is in effect when you run your application; this may contain additional or different jars than the build path, because (for instance) your app might compile against an interface (IFoo) but reflectively load an implementation class (Foo) at runtime.

Often the runtime classpath is the same as the build path, but ultimately it's controlled by the launch configuration. Sometimes the app itself (or code in jars it references) may extend the classpath by loading libraries from specific URLs or disk locations; that's why I've been emphasizing the need to make sure where your app is running from, in case it is internally trying to dynamically load a library with a relative pathname.

You probably want to Run As... Java Application. Once you've done this once, there will be a launch configuration; if you go to the dialog, you'll notice there are a bunch of tabs. I'd suggest paying attention to the contents of each of those tabs; in particular, the field that lets you set the directory that the application will be launched in.

This example is from Galileo. The process has gotten much better over the years. Once, you could usually expect it to fail and you'd have to install new software components by hand dropping myriad JARs into the Eclipse plugins subdirectory (now named dropins). I have done many of these in recent times (read: Galileo) and not had anything thing (or repository site) go missing. If that weren't enough, I "dropped in" AnyEdit tools by hand (something I've grown used to) only to find it supported by the update manager anyway.

1. Choose Help -> Install New Software -> Work with: -> All Available Sites.

2. Wait for list to populate; this can take a while.

3. Select something such as the Eclipse Data Tools Platform.

4. Click Next. Eclipse calculates requirements and dependencies. There could be a lot of these.

5. Click Finish. Wait patiently a long time. Usually, bouncing Eclipse will be required afterward.

When the application you're running (or debugging) from Eclipse needs to load shared-object libraries (on Linux, duh), you need LD-LIBRARY_PATH set up, but how? The trick is simply to set it up before launching Eclipse, which you must do from the command line:

	russ@taliesin:~/dev/run> export LD_LIBRARY_PATH=`pwd`
	russ@taliesin:~/dev/run> ../../eclipse/eclipse

If your application (or its dependents) are clever enough to say right out that they can't find a native shared-object library (JNI or JNI-dependent, etc.) because it's not on the java.library.path, you do not want to modify what Eclipse thinks this path is.

Instead, determine which JAR contains the code that wants to load the JAR and fix it in Build Path. Do this:

1. Right-click on the project in Eclipse.
2. Choose Build Path, then Configure Build Path, then click the Libraries tab.
3. Find the library containing the JAR and expand it (or simply the JAR if it was added as a mere JAR).
4. Expand the JAR by cliking the little triangle to its left.
5. Click on Native library location: and then Edit.
6. Fill in the path by hand or by browsing to the directory containing the native shared-object in question.
7. Click OK, then OK.

Once you've deleted an old project, possibly through refactoring, it may persist in the workspace and Eclipse will not let you reuse it. You'll find a record of this on the path:

	.metadata\.plugins\org.eclipse.ltk.core.refactoring\.refactorings

You may simply delete the project you'll find there, a rather deep directory structure, and then use the name again. Be sure this is what you want.