4

I have a series of related projects that I've placed under Git control (all these projects are in the same workspace, which is the top-level of the Git repository) and cloned from my desktop (32bit) to my laptop (64bit) so I can work on them wherever. The workspace .metadata folder is excluded, but everything in the project folders is tracked.

When I opened the cloned workspace on the laptop, I was greeted by an error:

Project 'project' is missing required library:
'/usr/eclipse/plugins/org.eclipse.swt.gtk.linux.x86_3.5.2.v3557f.jar'

Obviously, the 64bit eclipse doesn't have the 32bit libraries, but I'm curious as to how this should be resolved.

That library was added as part of the Window Builder SWT/JFace Project template. There is a org.eclipse.swt_3.5.2.v3557f.jar in the eclipse plugins folder, but changing the classpath to look for that doesn't work (doesn't find SWT, oddly). Looking through the rest of the .classpath file for the SWT/JFace projects, this particular library is the only one that is so platform specific.

I put both versions of the library in the .classpath and this allows the code to build/run, though I have to ignore the build path error, and this error will propagate back to my desktop when I pull the laptop changes back.

Can I just symlink the 64bit jar on the laptop to the 32bit name so the classpath can find the library? Is there another, better solution?

UPDATE: It looks like this type of project has to depend on the concrete SWT fragment, so until there's a better solution I'm going to symlink the fragments in question on both machines to direct the compiler to the correct fragment. Building/running the projects on other machines (and especially Windows) will be !!Fun!! but I'll build that bridge when I get there.

Erik Youngren
  • 783
  • 1
  • 6
  • 15
  • Come to think of it, why the hell is this writing classpaths with platform specific paths? If I took this to a Windows machine it wouldn't be able to find _any_ of the things it needs to run... Hell, the docs at the Google Code page say the classpaths start with `C:/eclipse/plugins/` – Erik Youngren Dec 05 '10 at 06:52

4 Answers4

1

Don't do it with the whole workspace. Just do it with the individual projects. Works well here.

Thorbjørn Ravn Andersen
  • 73,784
  • 33
  • 194
  • 347
  • All the projects in this particular workspace are logically related, but not enough to be the same project. I _want_ them in one repository. – Erik Youngren Dec 03 '10 at 23:49
  • You can do that by adding each Eclipse project individually to the repository. Do not add the whole workspace. – Thorbjørn Ravn Andersen Dec 04 '10 at 08:24
  • Thinking back on what I was doing to get them all in the repository (as far as Eclipse was concerned--how to manually tell eclipse a project is under git control is another question), I was in fact doing just that. – Erik Youngren Dec 05 '10 at 06:12
  • Create the git folder and put All projects in the git folder, and then just add Them all A's any other folder. Remember to ignore the bin folders. – Thorbjørn Ravn Andersen Dec 05 '10 at 12:47
1

What exactly are you keeping in your source control?

The best practice is to keep only hand-written source files on source repository. Not binaries, or generated files, or IDE settings.

I think you have the problem with the IDE settings for your 64bit Eclipse not working with 32bit one.

Just delete .metadata directory in your workspace, and reimport all projects in this Eclipse.

Goran Jovic
  • 9,418
  • 3
  • 43
  • 75
  • And of course, put .metadata on ignore list, so that you wouldn't override them on next commit. – Goran Jovic Dec 03 '10 at 22:47
  • Just the project folders, and a top-level empty `README` left over from the first commit. So, source and the per-project configuration files, basically. `.metadata` was thrown on ignore when I noticed it was several megabytes. – Erik Youngren Dec 03 '10 at 23:54
  • Oh yes, you should remove `.settings` from your project directory, too. – Goran Jovic Dec 03 '10 at 23:59
  • You should keep on your repository only the source, various xml configs and stuff like that. Only your code, not things related to IDE. – Goran Jovic Dec 04 '10 at 00:00
1

Which type of the project you are developing? The java project or plug-in project?

If you're developing plug-in project, your project should not directly depend on the concrete swt fragment(such as swt.gtk, swt.win32). It should depend on the host plug-in 'org.eclipse.swt' that the actual implementation of swt is the different fragments in different platforms.

If you're developing a java project that requires the swt as the third-party requirement. You can install eclipse delta package for both your 32bit and 64bit eclipse.

Kane
  • 8,035
  • 7
  • 46
  • 75
  • Now we're getting somewhere. I thought it was weird that it was including something so specific, but I assumed the project template knew what it was doing. I was starting with a WindowBuilder SWT/JFace Java project, which automatically added these libraries. Replacing it with the generic jar causes it to not know what SWT is. – Erik Youngren Dec 05 '10 at 06:22
  • @Artanis, first of all the implementation mechanism of swt decides that it doesn't pure of "cross platform" which uses jni to call native library. Then WindowBuilder SWT/Jface project is a java project, it puts all referenced eclipse plug-ins into classpath for building and running. It doesn't use osgi to handle the classpath though it also requires the osgi jar. So the project has to depends on the concrete swt implementation for building and testing. – Kane Dec 06 '10 at 02:59
  • @Artanis, if you are using WindowTester to test your rcp project, I suggest you create junit plug-in test that could handle such problem well. – Kane Dec 06 '10 at 03:03
0

To avoid platform issues, you could also consider Maven. Using Maven 2 or 3, with optional combination of profiles platform issues can be resolved quite easily. Using a few Maven plugins for Eclipse, Maven projects can be imported into Eclipse directly.

Gerbrand
  • 1,561
  • 1
  • 12
  • 20