Here's how we do it at Systronix. This approach simplifies using code from public repositories such as java.net. It also eases sharing JAR files, aJile Jembuilder projects, and other aspects of a build.

1. Create a PROJECTS folder in each programmer's local or network hard drive.This is the "sandbox" into which programmers check out files from our version control system (we use CVS). Periodically (at least daily if changes are being made), code is checked into CVS.
2. For each project you wish to manage, create a meaningfully-named folder directly below the PROJECTS folder. This is the root folder which Eclipse uses for each defined Eclipse project. For example, JCX is a project.
3. When you start a new Eclipse project (File>New>Project>Java Project), do not use the default "Project Contents" location. Use a subfolder below the PROJECTS folder. This Eclipse project folder contains:
1. your Ant build.xml file
2. Eclipse .project and .classpath files
3. JemBuilder .ajp project files
4. Subfolders for source, class, doc and other files as described below
4. Within each Eclipse project, create subfolders:
1. src (for source code)
2. classes (for class files)
3. doc (for Javadocs)
4. html (for Amulet compiled HTML files)
5. JStampRamBuild (this is where output from JemBuilder should go for a JStamp build which will execute from SRAM)
6. TiniBuild for executable output from a TINI build
7. JStikFlashBuild for output from JemBuilder for a JStik build which will execute from Flash
8. SnapBuild for SNAP's executables (there is only one kind of SNAP build)

Note that there are separate executable files for each specific embedded platform build, including RAM and Flash versions, as applicable.

Make your local cross-compilation paths relative to Eclipse Java Classpath Variables. This provides the same portability and easy maintainability as System Environment Variables (see setting up environment variables). Eclipse does not use your System Environment Variables, and neither does Ant when executed within Eclipse (but Ant executed from a command line does). Setting these Eclipse Java Classpath variables to be identical to your computer's System Environment Variables makes all three builds a lot more compatible.

This also lets you install tools such as Dallas TINI runtime in folders such as TINI1.12, TINI1.13, etc, and refer to them in a given Eclipse project by changing a single project variable.

Set these up in the Eclipse Window->Preferences->Java->Build Path->Classpath Variables menu (see this screen shot). Now you can have a local hard disk folder such as "D:\TINI1.12" and refer to it as TINI_HOME both within Eclipse and within your Ant build files. So far, we've just created the variable -- it hasn't been actually used.

Now that the Eclipse Java Classpath Variable is set up, you need to use it in your Eclipse project. This must be done on a project-by-project basis (I haven't discovered how to make it apply to ALL Eclipse projects by making it an Eclipse Workspace setting). Open the Eclipse Project->Properities menu, select the Libraries tab and then click the Add Variable Button. A New Classpath Variable Entry box will popup. Select the TINI_HOME variable and click the Extend button (screen shot). Browse to a subfolder which you want to make relative to the Classpath Variable (screen shot) and select it. Now you have a new Java Build Path Library which is relative to your new Eclipse Variable (screen shot).

In this example we created a library path for tiniclasses.jar which is relative to our TINI_HOME Eclipse Java Classpath Variable. Now we can redirect that Eclipse project to a newer or older TINI runtime just by changing that one Eclipse Java Classpath Variable in one place.

This error popped up today when I was checking out projects from a CVS respository into a new, clean Eclipse workspace.This error had me going for a while since the projects in question built fine on another PC, and built fine in the new workspace, using Ant instead of Eclipse. It turned out that the reason the base class java.lang.Object could not be found is because the new workspace did not have Eclipse variables set, and they were referenced by the checked-out project. So in the project properties Build Path I'd see Classpath variables such as AJILE_HOME and JAVA_LIB being used to reference required libraries, but in fact Eclipse had no idea where "AJILE_HOME" was, and therefore could not find the CLDC base classes. Once I created the Eclipse classpath variables and rebuilt the project, the errors went away.

The Eclipse Java Development Tools (JDT) include a perspective designed for working with Java projects. It consists of an editor area and the following views:
Package Explorer - to open this, use Window->Show View-> Other->Java->Package Explorer
Hierarchy - to open this, use Window->Show View-> Other->Java->Hierarchy
Outline
Search
Console
Tasks

It's not terribly obvious how to control Eclipse line width and line wrapping in your Java source files. Here's how and where:

1. Comment width and line wrapping is set in Preferences->Java->Code Style->Formatter, then click on the Edit button and select the Comments tab. I like Line Width for Comments to be 120.
2. Code line wrapping is set nearby, in Preferences->Java->Code Style- >Formatter, then click on the Edit button and select the Line Wrapping tab. I like a line width of 120 and indent size of 4.
3. Indentation is set separately, in Preferences->Java->Code Style- >Formatter, then click on the Edit button and select the Indentation tab. I like an indent size of 4, consistent with the Line Wrapping indent setting.
4. As if that's not enough, you can also set printer margins, tab size, etc, in Preferences>General>Editors>Text Editors where I set the Displayed Tab Width to 4 and Print Margin Column to 120 or more. You can also check the Show Print Margin box to get a faint vertical line at the printer margin column

Remember to save these in your code template!

Then to automatically buff up your code appearance, save your file first and then use the main task bar Source>Format option. I'm not aware of a way to "unformat" so this is why it's a good idea to save first, so you can cancel out of any drastic surprises and try again.

A possible bug? (2006.04.10) In Eclipse 3.1.0, code formatting applies to "single line" comments ( // this is an example) when they are wider than the current comment margin, but not when they are narrower. Example: I applied Source>Format to a .java file and it made all my single line (and multi-line) comments fit within 80 columns. Yuck. I changed the comment column width to 120, reapplied the Format and only the multi-line comments changed. Hmmm, rather annoying.

By default Eclipse performs and incremental build. This just doesn't seem to work reliably with the aJile tools. Admittedly that sounds purely anecdotal. So in my Ant build.xml file I always delete all class files and the aJile binaries so that a complete, 'clean' build is always forced. Here's the Ant init target to do this.

<echo>Cleaning build and output folders</echo>
<!-- purge all .class and key aJile binaries so we can never have an invalid build -->
<delete>
<fileset dir="classes" includes="**/*.class"/>
<fileset dir="." includes="**/build.bin, **/load.sod, **/JVM0.*"/>
</delete>

Note that this action deletes *all* aJile binaries in a project's subfolders. I typically have multiple binary output folders in a project - a different output folder for unit tests, sample application tests, and different folders for RAM and Flash builds, so the above action deletes the binaries from all of them.