In places, you see the following; the meaning is given.

• R —Release
• SR —Service Release
• RC —Release Candidate
• M —Milestone

Milestones and release candidates are not releases, they're just coordinated builds with more testing than normal builds.

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; in my case, the rather informal "russ". To change this, create a Launcher shortcut and type the Launcher -> Command as

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

Note: user.name is a Java property.

Alternative

It's also possible to change Eclipse workspace preferences to provide this.

1. Go to Window -> Preferences.
2. Click Java -> Code Style -> Code Templates.
3. Expand Comments, click Files.
4. Click the Edit button.
5. Recast the Java file-level template to contain "@author Russell Bateman".
   (Maybe add it on a new line in order to retain the general utility of the template.)

In this sense, it's not really "fixing" the value for Javadoc @author, but it achieves the same effect.

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.

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.

...a Visual Studio term, is "Content Assist" in Eclipse parlance.

Here's how to get rid of those (harmless) "No grammar constraints (DTD or XML schema)" warnings in Eclipse:

1. Pull down menu Window -> Preferences, go to XML -> XML Files -> Validation.
2. Change the setting of Indicate when no grammar is specified from Warning to Ignore.
3. Revalidate your project.

1. In the Eclipse Help menu, click About Eclipse.
2. Click on Installations Detail.
3. In Installed Software tab, click the plug-in to remove.
4. Click the Uninstall... button.

It's fairly easy to reconfigure the Eclipse workbench, relocate views, etc. just by clicking on a tab, dragging and dropping it somewhere else. Dragging a tab to an edge of an existing pane (view) will create a new pane on the workbench. Experimentation will soon have you fixed up.

However, there is some geometry that's not so obvious and it involves creating new pane at edges where there was none. Considerable experimentation is sometimes needed. For example, I wanted to know how to transform this arrangement of views in my Debug perspective:

+----------------------------------+-----------------+
| 1                                | 4               |
+----------------------------------+-----------------+
| 2                                | 5               |
+----------------------------------+-----------------+
| 3                                                  |
+----------------------------------------------------+

...to this:

+----------------------------------+-----------------+
| 1                                | 4, 5            |
+----------------------------------+                 |
| 2                                |                 |
+----------------------------------+-----------------+
| 3                                                  |
+----------------------------------------------------+

(For my terminology here, I'm going to call panes where the (numbered) views are located. E.g.: above, views 4 and 5 occupy the same pane. The UI control for grabbing and dragging a view is the tab on which its name sits.)

The steps were easy enough, but they must be done in just the right order:

1. Grab/drag view 5 all the way to the right until you get the indicator icon of an arrow pointing left. This will place 5 in its own pane on the right end of the full length of the workbench, creating:

   +----------------------------------+------------+----+
   | 1                                | 4          | 5  |
   +----------------------------------+------------+    |
   | 2                                             |    |
   +-----------------------------------------------+    |
   | 3                                             |    |
   +-----------------------------------------------+----+
   

2. Grab/drag view 3 down until the indicator icon points up. This makes view 3 a full-width pane below views 2 and 5.

   +----------------------------------+------------+----+
   | 1                                | 4          | 5  |
   +----------------------------------+------------+    |
   | 2                                             |    |
   +-----------------------------------------------+----+
   | 3                                                  |
   +----------------------------------------------------+
   

3. Grab/drag view 4 on top of (into the same pane as) view 5 and resize the 4, 5 pane. This produces the result above (the second illustration).

In my Debug perspective, these panes were:

My ultimate Debug perspective layout is as below since I like lots of room for source code and variables. I only dragged my JUnit view up into the same pane as Variables and Outline. My monitor dimensions are 1920×1080.

+----------------------------------+-----------------+
| 1                                | 4, 5, 3         |
+----------------------------------+                 |
| 2                                |                 |
|                                  |                 |
|                                  |                 |
+----------------------------------+-----------------+

If you've renamed an Eclipse workspace or otherwise no longer wish to be bothered seeing it as a suggestion when you switch workspaces, do the following:

1. Under the Eclipse home subdirectory (where it's installed in your filesystem), find the following file:
   
   (eclipse-home)/configuration/.settings/org.eclipse.ui.ide.prefs
 
2. Edit the file, and look for the line that starts with: "RECENT_WORKSPACES".
 
3. The workspaces are separated by newlines (Linux, at least); delete whichever workspace you no longer wish to appear in the drop-down menu.
    
4. Save the file.

In recent Ubuntu releases, the default desktop theme has been "Ambiance" (unless I'm mistaken). I don't mind this at all, however, when you're working in the Eclipse workbench, it makes a number of things miserable. For example, Javadoc isn't particularly readable nor are error strings when you hover over the error. These are all a dark back ground with black text. (What's in a yellow background below is dark in the default theme.)

I stumbled upon the "ClearLooks" theme which works much better. I admit that the white background is a little stark and I may experiment with modifying that (click the Customize button), but certainly things are better with it than with the default. To get this, do System -> Preferences -> Appearance and choose "ClearLooks".

Yes! It is possible!. I found that this just used Eclipse's own format and not mine unless the project was carefully set up. The project itself (and not just the workspace properties) must be enabled for this. Also, you cannot use your saved .xml file containing your formatting properties directly as the argument to the -config option.

While you have to use settings down under an existing Eclipse project, the Java file you're formatting doesn't need to have anything to do with that project (or any other).

1. Choose the project whose formatting properties you intend to make use of.
2. Right-click on the project and choose Properties.
3. Expand the triangle next to Java Code Style.
4. Click Formatter.
5. Click Enable project specific settings.
6. Import your profile (if you like) and make it the Active profile.
7. Click OK.
8. Exit Eclipse (to ensure the settings are saved).
9. Fill in $WORKSPACE and $PROJECT in this script.
10. Execute this script with the file you wish to format as argument, or the subdirectory whose files you wish to format.

	#!/bin/sh
	WORKSPACE=/home/russ/blackpearl/workspace
	PROJECT=TryStuff
	SETTINGS=$WORKSPACE/$PROJECT/.settings

	/home/russ/dev/eclipse/eclipse -nosplash \
		-application org.eclipse.jdt.core.JavaCodeFormatter -verbose \
		-config $SETTINGS/org.eclipse.jdt.core.prefs \
		$*

Eclipse deploys the web application you're developing internally for testing on the path below.

<workspace>/.metadata/.plugins/org.eclipse.wst.server.core contains tmp0, tmp1, etc. tmp0 as the first server you create, for example, using Apache Tomcat v6.x while tmp1 is the second, for example Apache Tomcat v7.0.

When you remove an application from a server (right-click server and choose Add and Remove...), then clean it (right-click server and choose Clean), Eclipse cleans up, mostly by deleting everything under workspace/.metadata/.plugins/org.eclipse.wst.server.core/tmp0.

Of course, when you're ready to deploy your application formally to Tomcat on a server, you must export it as a WAR file.

Start Eclipse in US English (or any other language) with the following option on the command line:

	-nl en_US

To control how your Java code is formatted, go to Window -> Preferences -> Java -> Code Style -> Formatter. There, you'll probably see (because you've likely not changed it) that the code formatter you're using is the default shipped with Eclipse.

If you click the Edit button, you'll be able to change a lot about how things are done. For instance, by working with the braces, you can change from using Kernel Normal Form (KNF) to, say, Allman indentation (as used by ANSI and ISO).

And you can dramatically affect the way other things are physically formatted not only as you type in code, but also as a result of selecting code and doing Source -> Format in the editor.

You can save your changes under a different name by giving your new format a name and clicking on the Export... button. This saves your changes in an XML file.

Conversely, when you create a new Eclipse workspace, you can go to Window -> Preferences -> Java -> Code Style -> Formatter and click the Import... button, navigate to that file you saved and thereby substitute it for Eclipse's default format.

From an existing Eclipse project, you can ask Eclipse to generate a suitable build.xml (or its contents and ask it to name it something else). Then, from that ant script, Eclipse will generate the project all over.

This is interesting because you might collaborate on a project with others, committing your work to Subversion, CVS, Git, etc. It's pretty straightforward. In order to make this work, here's what I had to do:

1. Generate the build.xml file by right-clicking on project, choosing Export -> General -> Ant Buildfiles -> Next -> select project by name -> name build.xml -> Finish
2. Copy off the whole project somewhere (into Subversion, etc.). This should not include product subdirectories such as build or bin, etc. Also, you don't need .classpath, .project or .settings, although missing .settings might be why a Dynamic Web Project done this way will degenerate into a simple Java Project.

Now, pretend you're getting this new project...

1. Copy the project to the workspace as-is. (Note: this is not how you would do it if you were creating a project directly from existing sources rather than from build.xml—that's another topic.)
2. Launch Eclipse and open the workspace where the project was copied (it will not show up in Eclipse yet).
3. Do File -> New -> Project... -> Java Project from Existing Ant Buildfile.
4. This should create and open the project.
5. Right-click the project (in Project or Package Explorer) and choose Build Path -> Configure Build Path... -> Libraries.
6. Remove JRE_LIB (obsolete—not sure why Eclipse does this, then tells you it's obsolete), click Add Library and add the JRE System Library set up for your workspace.
7. You'll do similarly for JUnit if you're using that.
8. This should make the project usable. You can open build.xml in the Ant view and/or simply allow Eclipse to build your project.

Not covered here...

How to establish a proper build.xml doing all the "real" things you'd set it up to do while accomplishing what's recounted above. The generated build.xml, which you may have named something else, tells you not to modify it since you could end up regenerating it again.

Part of the answer is to maintain a separate build file with additional stuff it in; you could call it from build.xml via <antcall target="myotherone.xml" >.

Another idea might be simply to maintain separate build files, trying to cut down on duplication of content. The top of the generated one contains the real contribution in the form of documenting what third-party JARs you're using. That's really why you'd regenerate, especially if you weren't too ant-savvy and wanted Eclipse to do this for you. But then, you'd likely not have addition stuff anyway, so there wouldn't be a conflict.

Based on some of the sections on this page, in particular the last two, the following is a how-to.

Creating a project

1. Create a project of any sort in Eclipse and develop it to the point at which you're ready to share it.
 
2. Create a clean or cleanall target in build.xml that removes all development (compilation) projects. This means .class files and other intermediate targets that are built as part of the development process, i.e.: not source files, property files, or "irreplaceable" resources such as JARs.
 
3. Ensure all (third-party) JARs consumed reside under subdirectory lib in the project. Sometimes, web application developers put these under WebContent/WEB-INF/lib. Doing that is a bit of an over-kill and it may confuse your new colleague to have to go find them in a deeper-than-necessary path.
 
4. Commit the subdirectories and source files described above in your source code/version-control system. Do not commit, in particular, .classpath file, .project file or the .settings subdirectory. In fact, add these to your version-control system's method to ignore them (.cvsignore, .gitignore, etc.).

Consuming a project

1. Check out, clone or update the project from version control into its own, suitably named subdirectory in the filesystem of your development host. Do not locate this subdirectory in any Eclipse workspace.
 
2. Launch Eclipse on the appropriate workspace.
 
3. Create a new Java Project, Dynamic Web Project or other using the usual wizard, but take care to dictate to it (it's about the second thing you do) that the sources are located in another subdirectory. Finish answering questions in the wizard as usual.
 
4. Once the project is created, right-click its name in the Project/Package Explorer and choose Build Path to add the libraries residing under the lib subdirectory. Add them also to the Deployment Assembly (new name beginning with Helios).

It's not possible to share workspaces, but you might get away with sharing the same project. Even via Dropbox. Here's how.

1. Create the project on one computer, get it more or less how you'd like it (i.e.: simple Java Project, Dynamic Web Project, etc. as created by Eclipse). You'll be able to add or delete source code later, but the project should exist enough for Eclipse to recognize it.
2. Copy the important parts of the project to your dropbox location.
3. From inside Eclipse, discard the original project including source files (it prompts you to be cautious about this).
4. Create a new project in the same (or a different) workspace. When the wizard comes up, you can name it what you want, but tell it to get the source files from another location and not to copy them into the workspace. Eclipse will consume the project from dropbox, I think.
5. Repeat this from your other computer from its Eclipse using, obviously, its own workspace.
6. The changes you make from one computer will be reflected in the other. You will have to right-click your project and choose Refresh when you change computers.
7. All third-party libraries (JARs) must be copied to a path inside your project. Otherwise, your .classpath file will acquire full filesystem pathnames which will not hold true on both computers. Another way of causing this problem is to associate Javadoc or source code with any of those third-party JARs (let's say you wanted Javadoc for hibernate3.jar, you're screwed as soon as you do that).

I have not done this; there may be a hole in what I'm telling you or, you may accidentally do something that destroys your ability to do it this way (as suggested by #7).

It's better to use a version-control system for this (and, obviously, there are other benefits too).

Note: I know what Dropbox is and have used it very briefly once. I don't know all the peculiarities of it. So, I may be making unwarranted assumptions on doing this.

You've killed a few workspaces, but they keep showing up in Eclipse's workspace start-up dialog (or when you switch workspaces via File -> Switch Workspace) and you want to forget them.

These are kept in a configuration file on the path <eclipse>/configuration/.settings/org.eclipse.ui.ide.prefs, in a variable, RECENT_WORKSPACES.

But there is a right way to maintain these. Go to Window -> Preferences -> General -> Startup and Shutdown -> Workspaces.

When using Eclipse on a box working through a VPN, you might encounter freeze-ups or slowness. Sometimes setting proxy information can fix this by isolating Eclipse from running any background processes through the VPN instead of on the box itself.

1. Go to Window -> Preferences.
2. Type "proxy" into the Search box.
3. Add stuff from /etc/hosts such as shown here:

Eclipse's .classpath file lists all the JARs that support your project and performs some other tasks such as supply links to Javadoc for those JARs that you set up if in coding you wish to see more usefully the interfaces therein or, when debugging, sources if you wish to step debug down inside them.

The JARs are thereby considered to be "on your class path" for the purpose of compilation, but as noted above, also for the Eclipse Java editor's use in implementing Content Assist—Eclipse's version of what Visual Studio calls Intellisense and for the debugger's use.

When you are in Build Path -> Configure Build Path -> Libraries (tab) and making changes, Eclipse needs write access to this file.

You're led to think that this can be placed into your Java code as if an annotation, but in fact it's not. You must use it commented out (and it works as long as you have Preferences -> Java -> Code Style -> Formatter -> Edit -> Off/On Tags -> Enable Off/On tags checked.

    /**
     * @formatter:off
     * This method will perform...
     *
     * @param str is the string on which...
     * @return the new string.
     * @formatter:on
     */

...or, in Java code...

    // @formatter:off
    [nothing here will get reformatted by Eclipse...]
    ...

    for( String a Title : DvdCreateTestTitles. titlenames )
    {
        ...
    }

    ...
    [...until beginning here again]
    // @formatter:oon

Beginning with Eclipse Indigo, I use Help -> Eclipse Marketplace... to install plug-ins I want. If you're behind a firewall and need a proxy, this might simply not work until you tell Eclipse this is what you're doing. Go to Window -> Preferences -> General -> Network Connections:

Only then can you use this facility.

Here's how to get Eclipse with its icon into the Unity task bar.

1. Download Eclipse first.
2. Explode to favorite place; you must know the path for the next step.
3. Create a file, opt-eclipse.desktop, not in the ~/Desktop subdirectory, but in another^* with the contents below.
4. Launch the (Nautilus) file explorer and open the subdirectory where you put the short-cut file.
5. If the short-cut does not have the proper icon, you may need to
   1. Right-click it and choose Properties.
   2. Click the icon in the properties and navigate to the Eclipse subdirectory to find icon.xpm.
6. Drag this short-cut into the Unity task bar. You can arrange the order of icons in the Unity task bar by clicking and dragging the icon out of the bar, then back to the bar in the place you want. If you attempt to click and drag up or down within the bar, it will move the whole bar instead.

    [Desktop Entry]
    Type=Application
    Name=Eclipse
    Comment=Eclipse Integrated Development Environment
    Icon=/home/russ/dev/eclipse/indigo/icon.xpm
    Exec=/home/russ/dev/eclipse/indigo/eclipse
    Terminal=false
    Categories=Development;IDE;Java;

^* Anything you put into ~/Desktop will show up on the desktop which is probably not what you want. You cannot "add, then delete it" since the short-cut is a permanent configuration Unity uses.

If you add a new ant task, in the Ant view in Eclipse, you may get to see something like this instead of being able to see and execute the ant targets:

    project-name <taskdef class package-name.task-name cannot be found using the classloader \
            AntClassLoader[/home/user-name/path/eclipse/plugins/org.apache.ant_1.8...

(A specific example is adding a findbugs target and seeing:)

    MyApp <taskdef class edu.umd.cd.findbugs.anttask.FindBugsTask cannot be found using the classloader \
            AntClassLoader[/home/russ/dev/eclipse/plugins/org.apache.ant_1.8.2.v20120109...

The solution may be the following:

1. Windows -> Preferences.
2. Ant -> Runtime.
3. Ant Home Entries (Default) -> Add JARs.... (this will go to a local path)
4. Navigate to and add the JAR.
5. In the Ant view, kill the project's build.xml and go get it again.

This should fix the problem.

Especially when developing a Dynamic Web Project, the Package Explorer view is real junky. I turn most of it off this way:

1. Look for and click a downward-pointing triangle toward the right end of the pane menu bar containing the Project Explorer view.
2. Choose Customize View....
3. Click the Content tab.
4. Unclick everything except the following:
   • JPA Content
   • JAXB Content
   • Enhanced Java Rendering for Web
   • Java Elements
   • Resources
5. Click OK.

From this point on, your src and test subdirectories are still obfuscated by Java Resources, but that's the worst of it. Also, a lot of fluff that I don't ever use is gone, which cleans up the view a lot.

When debugging, or attempting to access source in the editor, you stumble upon a message, "Source not found." There's a button, Attach Source... that you can click. Do this.

If the source is in your workspace (unlikely), then you can click the Workspace... button.

If in a file external to your workspace, that is, you have the source somewhere, you can click External File....

The most common is to have a folder of external source that you want to use as a resource. Click External Folder.... Navigate to the com parent directory to that source, select it and click OK, then again in the Source Attachment Configuration dialog, click OK.

FindBugs can be useful, but it can also be annoying and misleading with the bugs it finds (especially lots of null pointer stuff that isn't really a problem). You have to decide on a case-by-case basis.

To install it, use Help -> Eclipse Marketplace... and search for "findbugs".

When installed, right-click a project and choose Find Bugs ->Find Bugs. It will mark up (annotate) your Java code in the left margin of files with what will show up as warnings in the Problem view. Turn this crap off by right-clicking and choosing Find Bugs -> Clear Bug Markers.

If you download findbugs-ant.jar, wishing to consume it from build.xml, it goes on a path where it can be consumed locally, e.g.: project-name/lib/non-deploy/findbugs-ant.jar. Here's a sample ant target:

    <!-- == F i n d B u g s ( t m ) =========================================== -->
    <taskdef name="findbugs" classname="edu.umd.cs.findbugs.anttask.FindBugsTask"/>

    <property name="findbugs.home" value="/home/russ/dev/downloads/findbugs-2.0.2" />

    <target name="findbugs" depends="build-compile"
	        description="Run FindBugs on compiled code and libraries.">
        <findbugs home="${findbugs.home}"
                  output="xml:withMessages"
                  outputFile="${extras.dir}/findbugs.xml" >
          <auxClasspath path="${flat_libs.dir}/*.jar" />
          <sourcePath path="${src.dir}" />
          <class location="${build.dir}/classes" />
        </findbugs>
		<style    in="${extras.dir}/findbugs.xml"
		         out="${extras.dir}/findbugs.html"
			   style="${extras.dir}/findbugs.xsl"
		/>
    </target>

Window -> Preferences > General -> Text Editors -> Insert spaces for tabs is not how to exchanges spaces for tabs in the Java editor, but only the "default" text editor.

Window -> Preferences -> Java -> Code Style -> Formatter -> Edit (button) -> Indentation -> Tab Policy -gt; Spaces only is how to force it in Java.

Click the downward-facing triangle in the Project Explorer views menu bar.

Choose Customize View..., then click the Content tab. Uncheck everything except:

I did not try this for Indigo, which isn't guaranteed to work. Maybe someday.

1. Downloaded JDK 8 from java.sun.com.
2. Wired it up to Kepler.
3. Wrote code requiring Java 8 (static default method in interface).
4. Count not set compliance to 1.8.
5. Updated Kepler to SR2 and restarted.
6. Still no 1.8 option for Properties -> Java Compiler -> Compiler compliance level:.
7. Use Help -> Install New Software:
   1. Added Eclipse 4.3.2 Patch Build
      http://download.eclipse.org/eclipse/updates/4.3-P-builds
   2. Checked Eclipse Java 8 Support (for Kepler SR2).
   3. Click Next.
   4. Select Eclipse JDT.
   5. Click Next.
   6. Accept EULA.
   7. Click Finish.
   8. Restart.
8. Found 1.8 as option for Properties -> Java Compiler -> Compiler compliance level:.
9. Appears to work.