Eclipse projects on removable media

[Frank Carver]

It's been a while since I last worked on some of my Java projects, and in the meanwhile I have upgraded the USB drive that I store my projects on. As a side effect it now mounts as drive G: rather than drive F: as my old one did.

For most things this works fine. Eclipse, however, has a big problem with this, having hard-coded the drive letter in the project information somehow. If I try to open one of these projects it just complains about a missing ".project" file. The file, of course, is there, but now on drive G.

There doesn't seem to be any option for changing the location of a project in the project list panel, right-click and select properties shows the offending assumption, but offers me no way to change it.

I have 20-30 projects listed which I can not open. Can anyone help?

[Tim Holloway]

I believe you can just import them (filesystem import). You might have to define the projects themselves first (just do a File/New/empty project), for each project.

[Frank Carver]

I don't think import is quite the right answer. If these projects were just on the filesystem and not already listed in Eclipse, I'd agree, but they are already "in" Eclipse.

If I try to create a new project with the same name, Eclipse complains.

I suppose what I really want is a way to tell Eclipse that the directory holding the project files is relative to the Eclipse base workspace directory rather than an absolute location. This is something that we can already do _within_ a project (for jar files, etc.) but the last step seems to be missing.

On a philosphical note. I feel sometimes that removable media is a major new frontier for software developers. A few years ago the challenge was networks and internet resources, but these days most everything lets you load from an arbitrary URL.

But so many application designers insist on burying their heads and assuming that a file, once created, will always be in the same place. With USB storage growing bigger, faster, and more flexible every day this assumption simply cannot hold. I want to install my own favourite application collection onto my USB thumb drive, and have them all work seamlessly whatever drive letter or mount point is assigned to the drive whe I plug it in. Is that too much to ask?

[Tim Holloway]

It's important to distinguish between a Project and the files that make up a Project. If you have a Project, and it's pointing to files in the wrong place, you have to correct the project. Ways of doing this include:

1. Defining a whole new project workspace and starting from scratch (leaving the old workspace alone in case of future need).

2. Deleting the incorrect parts of the project.

3. Deleting all the files in a project, leaving an empty project

4. Renaming the project and creating a new, empty project having the original project name.

The Eclipse Import facility imports files, not projects, so once you have a suitably clean project you can import the contents (files) of your old project into the new Eclipse project.

It's possible to make Eclipse projects pretty much location-independent. I do this all the time. Mostly it involves using relative-location definitions in the .classpath and using symbolic base locations for things like TOMCAT_HOME (instead of C:\usr\local\tomcat).

Making the entire project arbitrarily mobile might be a strain. I've never attempted to make the "Project" relocatable, just the project contents. That is, I can team-commit a project to CVS that lives in my local C:\projects directory, go to a Linux box, and check it out under /home/mydir/workspace and expect everything to work OK, but I don't migrate the project around within the machine willy-nilly, and wouldn't really want to. Even if the machine didn't get confused, I almost certainly would.

I know that recent Fedora releases are pretty good about consistently mounting unique devices at the same mountpoint, and while I haven't looked at the details lately (or for USB devices), I do know it was possible to lock down CDROM drive IDs as far back as Windows 4.0.

[Frank Carver]

Originally posted by Tim Holloway:

Making the entire project arbitrarily mobile might be a strain. I've never attempted to make the "Project" relocatable, just the project contents. That is, I can team-commit a project to CVS that lives in my local C:\projects directory, go to a Linux box, and check it out under /home/mydir/workspace and expect everything to work OK, but I don't migrate the project around within the machine willy-nilly, and wouldn't really want to. Even if the machine didn't get confused, I almost certainly would.

I know that recent Fedora releases are pretty good about consistently mounting unique devices at the same mountpoint, and while I haven't looked at the details lately (or for USB devices), I do know it was possible to lock down CDROM drive IDs as far back as Windows 4.0.

I understand where you are coming from with this, but unfortunately I still have problems if the configurations of directories used to store project files are not "mobile".

The main problem is that I develop on several different machines. At a minimum my office workstation and my laptop, but also often machines at client sites or at the college where I teach part time. Synchronizing anything between all these different machines is an unworkable nightmare, so I long ago took to storing all my changeable data (project settings, source code, etc.) on removable media.

You are right that any particular machine usually mounts the same removable device on the same drive/mountpoint. However, these different machines each mount my USB drive on different drives: My workstation used to use drive F, but now prefers drive G since I added a USB hard drive and upgraded my USB flash drive from 256MB to 1GB. My laptop has a built-in multi-format card reader that grabs drives up to about K, and client/college machines are both different again and usually locked down to prevent changing stuff like that.

I have installed Java and Eclipse on each machine, and can configure each one to use a directory on whatever drive letter the removable media uses on that machine as its project workspace. When I do that it "sees" the projects, but falls over when it tries to access the project files from a (hard-wired) drive stored in the project configuration.

There is no obvious engineering reason that I can find for storing the full, absolute path in such cases, when a path relative to the configured Eclipse project directory would do the job just as well, and also work in my situation.

A subsidiary problem is that I only have remote CVS access from some machines. I do most of my commits of my own projects from my office workstation (which has access to my own local CVS, and to Sourceforge). Often my laptop will have no network connection at all, and college systems typically prevent network access for stuff like this. With work for clients, I usually only have access to their code repositories (whatever bizarre system they may favour) when I am on-site and inside their firewall. So sharing via CVS (or whatever) is also not really feasible.

I just find it really irritating that the Eclipse UI teases me by showing the hard-wired project directory, but will not let me edit it to change it. Even if I wanted to change it to a relative path from the Eclipse project directory.

[Tim Holloway]

That's closer to what I do, and I have no problems doing it. Eclipse does support relative paths in projects if you set things up right.

On your classpath, avoid using the "external jar" option if you can. If you can't (that is, the jar really is external to your project's directory subtree), define a symbolic reference such as TOMCAT_HOME. Although the project build dialog is one way to do that, for multi-project situations, use menu "Window/Preferences->Java/Build Path" and set classpath variables and user libraries and you'll get global addressability for all projects.

Here's a sample of a complex project's ".classpath" file. Note that I've been bad and have some absolute paths near the bottom, but there are also relocatable paths (TOMCAT_HOME and ECLIPSE_HOME) in there as well. You can also see I'm paranoid and keep project-local copies of jakarta libraries, wasting some disk space in exchange for avoiding "version hell"

<?xml version="1.0" encoding="UTF-8"?>
<classpath>
<classpathentry output="build/server/classes" kind="src" path="server/src"/>
<classpathentry kind="src" path="server/test/src"/>
<classpathentry output="build/registrar/classes" kind="src" path="registrar/src"/>
<classpathentry output="webapp/test/classes" kind="src" path="webapp/test/src"/>
<classpathentry output="build/webapp/WEB-INF/classes" kind="src" path="webapp/src"/>
<classpathentry output="build/client/classes" kind="src" path="client/src"/>
<classpathentry output="build/spi/classes" kind="src" path="spi/src"/>
<classpathentry kind="src" path="allservers/src"/>
<classpathentry kind="lib" path="lib/jdbc2_0-stdext.jar"/>
<classpathentry kind="lib" path="lib/jakarta-regexp-1.1.jar"/>
<classpathentry kind="lib" path="lib/jcommon-0.9.1.jar"/>
<classpathentry kind="lib" path="lib/mx4j-jmx.jar"/>
<classpathentry kind="lib" path="lib/jca1.0.jar"/>
<classpathentry kind="lib" path="lib/kodo-jdo-runtime.jar"/>
<classpathentry kind="lib" path="lib/jta-spec1_0_1.jar"/>
<classpathentry kind="lib" path="lib/jakarta-commons-lang-1.0.1.jar"/>
<classpathentry kind="lib" path="lib/kodo-jdo.jar"/>
<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
<classpathentry sourcepath="ECLIPSE_HOME/plugins/org.eclipse.jdt.source_3.0.0/src/org.junit_3.8.1/junitsrc.zip" kind="var" path="JUNIT_HOME/junit.jar"/>
<classpathentry kind="lib" path="webapp/web/WEB-INF/lib/commons-beanutils.jar"/>
<classpathentry kind="lib" path="webapp/web/WEB-INF/lib/commons-validator.jar"/>
<classpathentry kind="lib" path="webapp/web/WEB-INF/lib/struts.jar"/>
<classpathentry kind="lib" path="webapp/web/WEB-INF/lib/struts-el.jar"/>
<classpathentry kind="lib" path="lib/classes12.jar"/>
<classpathentry kind="var" path="TOMCAT_HOME/common/lib/servlet-api.jar"/>
<classpathentry kind="var" path="TOMCAT_HOME/common/lib/jsp-api.jar"/>
<classpathentry kind="lib" path="lib/jdo-1.0.2.jar"/>
<classpathentry kind="lib" path="lib/jakarta-commons-collections-3.1.jar"/>
<classpathentry kind="lib" path="lib/jakarta-commons-pool-1.2.jar"/>
<classpathentry kind="lib" path="C:/usr/local/httpunit-1.6/lib/httpunit.jar"/>
<classpathentry kind="lib" path="C:/usr/local/httpunit-1.6/jars/nekohtml.jar"/>
<classpathentry kind="lib" path="C:/usr/local/httpunit-1.6/jars/xmlParserAPIs.jar"/>
<classpathentry kind="lib" path="C:/usr/local/httpunit-1.6/jars/xercesImpl.jar"/>
<classpathentry kind="output" path="server/test/classes"/>
</classpath>

I could make the test libraries relocatable if I wanted:

1. define TEST_LIBS=C:/use/local/httpunit-1.6/jars

2. Change the path entries in .classpath. e.g.,

<path="C:/usr/local/httpunit-1.6/lib/httpunit.jar"/>
<classpathentry kind="lib" 

<br /> Becomes<br />

<path="TEST_LIBS/httpunit.jar"/>
<classpathentry kind="lib" >

Note that Eclipse doesn't use "$" or other markers as variable indicators. It figures things out for itself.

[ November 22, 2005: Message edited by: Tim Holloway ]
[ November 22, 2005: Message edited by: Tim Holloway ]

[Frank Carver]

Thanks again. I do pretty much all of that already. My main problem is still that Eclipse can't even open my projects when the drive moves, because it has hard wired the path to (among others) it's own .project and .classpath files which contain all that stuff.

Do you have your Eclipse "workspace" on a single static hard drive so that the location of these files never changes?

Do you have any idea where Eclipse stores location of each project's metadata when you create one? So far I haven't been able to find it.