Accepted answer

the first solution that really seems to work so far is a little ugly but very easy. i just created a symbolic link in the /users/ directory to make eclipse find the needed files.

cd /users/
sudo ln -s username-on-the-current-machine/ username-in-the-path-of-the-classpath-file

that way i can easily share code between my different machines.

and a note on version control: yes, we use version control. actually, we work on a github fork of a university project with a lot of pull requests, branches and several developers. so the dropbox solution is not a substitution for an scm. however, it helps me to be very flexible in changing between different computers quickly and i do not have to handle branches, commits and so on just to keep the files up-to-date. but of course, all changes are committed to github when they are ready.


although your probably not going to do this given you have already answered the question... you really should not:

  • checkin .project and .classpath files
  • share projects files across different computers instead of using scm (particularly since your using git).

i believe ivy, gradle, sbt, and maven all have solutions for managing .classpath and .project. you should investigate those options. also eclipse has both a maven and ivy plugin ( which will automatically manage your your classpath for you based on the ivy and maven file.

as a developer that works on many other projects is rather annoying when some one checkins .project and .classpath. sharing outputted files across different machines (.class and .project, .classpath) is also dangerous. thats because you could have different versions of eclipse and different jdk compilers not to mention eclipse partially compiles java files. it may work for you now but its a hack.

also as i noted in a comment you'll either have to remember to refetch ivy dependencies or include those in your sync (ie your .ivy2 directory which can be absolutely massive) and since you'll have to remember to refetch ivy dependencies are you that lazy to not regenerate your .classpath (unless sbt is completely lacking on that) ?


you can remove the binaries folders from dropbox, by doing so everytime dropbox synch it only overrides your code, and eclipse will have to build again , and the problem should be solved.


there is no way to rename the .classpath file, it's one of the very few things that eclipse needs to be hard-coded in order to work (it, along with the .project file are the bootstraps by which java projects are managed; eclipse jdt has to inherently "know" where those files are).

i don't know anything about sbt, but in general there are several capabilities/techniques in eclipse java projects to keep .classpath clean (free from absolute or machine-specific paths). in a typical java project, the user makes changes to the project via the build path properties which result in changes to .classpath; does sbt re-generate that file periodically? can you post the contents of your .classpath?


i'm not familiar with sbteclipse, but according to their wiki page, running sbt eclipse will generate the .classpath file. the way you're running it, it's generating absolute paths for your dependent libraries, which you don't want.

there is a setting called relativizelibs that looks like it's the problem. you should set that to true (which is apparently the default value). you will then likely have to make sure you run sbt eclipse from the same relative location to the project and library files on each computer, but you should be able to make that structure consistent between your development machines.

Related Query

More Query from same tag