How to transfer Eclipse workspace and project from Windows to Linux and Mac

Question

We have a a product developed on Windows for years. The product is composed of one Eclipse workspace and about 20 projects. On Windows, we ask every developer check out projects into d:\dev\product folder, and copy a unified Workspace to d:\dev\prod_workspace. This way, whenever a new machine is set, we simply copy files to the same folder, and we can start working immediately.

No We need to move our development environment to Linux and Mac. But there's no D:\ on Unix. And home folder for Linux is mostly like /home/username and /Users/username for Mac. We found Eclipse keeps absolute path in workspace when referring to projects, so simply copy workspace over does not work anymore. Even when we manually create/configure workspace on a Linux machine, it still cannot be copied over to another user, because the absolute path is changed.

I guess our goal is to allow easy setup of development environment. Do you have any suggestion to move eclipse workspace around?

Thanks!

Li

Answer 1

I develop an Eclipse based product for Mac and WIndows (haven't tried Linux).

The solution I found to work best is to actually go and manually check out the projects in the workspace on each machine directly from source control. While the project structure does convert between platforms, any attaches, such as version-control stuff does not. I am not sure why, but I guess each thing has its kinks. You may be able to able to hasten things a little by creating a project working set (or whatever it's called, I think it's a PSF file) for a platform, and then reuse it on all platforms.

Another problem is that Eclipse versions are not 100% compatible. One of the problems I have is with manifest files for plugins, which have different semantics (e.g., what to do with exported packages that don't actually exist) in each platform, causing a headache.

Finally, be away that Java on Mac and PC are not identical. In fact, Eclipse has two versions for the Mac. I usually end up running and compiling on Java 5 on the mac, which does have some incompatibilities with Java 6.

Answer 2

I can think of two ways to do this:

1. Use workspace variables in Eclipse to point to the exact location where the workspace sits, if you need that. Then the developer can put everything in the workspace on Windows, Unix, whatever, then define the variable and you're done, or
2. If compilation is always done from within Eclipse, meaning you don't truly need any absolute paths anywhere, then change the projects to all use relative paths and check the Eclipse classpaths, etc, into source control. Thus, when a developer checks out everything in Eclipse, the classpath and .project file will be at the root level in the project and all paths will be pre-defined.

For option #2, you may need to have multiple .project or .classpath files, and have the developer copy the appropriate one into location. That is, copy .classpath.win into .classpath for Eclipse's use.

Answer 3

I have ported my eclipse project from windows xp to RHEL(never tried Mac)

Your task can be accomplished in the following steps :-

1. Use workspace variables in your project code rather than absolute path.
2. Shift your workspace to some location in linux as /Workspace or if you want to keep it user specific make the workspace folder as /home/user_name/Workspace.
3. There is an option to change all the \ of windows to / in linux. The option can be found under the file menu in eclipse.
4. Change the settings of where to find classpath directories, the options can be found by just right clicking on the project menu in the project viewer panel.
5. There is an option to build the project clean from scratch. You just have to click on the option and eclipse would re-compile the project.

Once all this is done, and all your database connections have been successfully ported to linux, you would have a working project running in linux as well.

Answer 4

If you check out the projects from a source repository, then consider using Team -> ProjectSets to handle these.

Preferences can be saved in a file and loaded.

We tried classpath variables and loathed them. Now we just have everything in single projects in the source repository.