2

So the way I gather it, eclipse stores its project specific files in two or three hidden files such as:

  • .project
  • .classpath
  • are there more?

Do I sync the .project file through the version control? the .classpath? (I'd assume not). To be able to import a project easily, I'd definitively assume the .project has to be there :p.

So my problem seems to be that it's not just to create a project on machine A, put the entire contents of the project folder on some version control, and import it on machine B. It always seems like it works wonderfully (as it should) on machine A, and becomes a mess with invalid classpaths for libGDX jar files on machine B, and we have to manually fix these afterwards by going into each libGDX 'sub-project' (since it has one project per target platform) and link it to the correct gdx.jar, gdx-native.jar etc....

Can't this be automatic? Am I doing it wrong? A lot of people probably use libGDX, and they probably collaborate right? So how do you do it? :)

2 notes here:

  1. I know this is a one time setup kinda thing, and once you do this, we un-track the .project .classpath files so they no longer mess each other up. But it's still a pain to do this for every project... I still think this should not be such a turn-off when starting a collaborative project with libGDX / eclipse.

  2. I was contemplating making this question more specific about libGDX, since this is what I am using at this particular instant together with others, but it would seem to be applicable to most eclipse projects anyway.

alex
  • 479,566
  • 201
  • 878
  • 984
GoodQuestions
  • 103
  • 7
  • I like to put those files in source control: http://stackoverflow.com/a/2819639/6309 – VonC Apr 09 '14 at 06:12

1 Answers1

1

OK, so I finally found a solution!

some info:

  1. eclipse does support relative paths (since 3.5 apparently) for libraries and the build path. (I want to credit @VonC, here: .classpath and .project - check into version control or not?)
  2. the libGDX setup tool creates an eclipse project for you (yay!), but it does so with absolute paths to the build path libraries (bad!)

solution:

apparently there is no nice GUI method of editing the .classpath file from eclipse that I could find (without navigating using the file browser), so open the .classpath file in a text editor, and change the path from absolute to relative like this:

  • "/some/absolute/path/to/project/libs/gdx.jar" ---> "libs/gdx.jar"

and here are my exact lib entries in the .classpath file for my project-desktop project (after making changes):

  • <classpathentry kind="lib" path="libs/gdx-backend-lwjgl.jar" sourcepath="libs/gdx-backend-lwjgl-sources.jar"/>
  • <classpathentry kind="lib" path="libs/gdx-backend-lwjgl-natives.jar"/>
  • <classpathentry kind="lib" path="libs/gdx-natives.jar"/>

These might be of interest due to them being relative paths (thus presumably identical to what others would want in many cases (libGDX cases!)).

version control?

Now (with relative paths) we can safely put all our eclipse project settings in our version control / repository, and anyone can just clone and run our libGDX projects with ease! :)

(I hope libGDX makes use of relative paths for their project setup tool in the future)

Community
  • 1
  • 1
GoodQuestions
  • 103
  • 7