If I add an external jar to my jme project it modifies the .classpath for the project. The external jar I'm adding is SWT.
However if I do this, the project is listed as having been changed. The problem with this is that every time I update the jme project to the head revision I have to re-modify the classpath.
Is there a solution around this?
mhh yeah, thats the downside of a checked in .classpath.
the only solution would be to delete it.
Just update the source tree, or update whatever needs to be updated - you can skip the classpath just by not updating the entire project tree.
Pyrrhus said:
Just update the source tree, or update whatever needs to be updated - you can skip the classpath just by not updating the entire project tree.
Yes seems like the best solution. :D
If you use the Team Synchronize view (which everyone should use anyway ;)) you can choose to import everything that doesn't conflict with your changes, and then review the remaining changes.
Ideally the only remaining change would be your uncommited version of the .classpath file, which you could then safely ignore.
If you do so, don't forget to remember that, shall any developer modify the .classpath by any reason, you would still need to update it and merge your changes.
I'm still a beginner with eclipse so I didn't know about this. TeamSync mode is cool. Thank you.
if more people find it inconvenient to have the .classpath checked in, we can delete the .classpath from svn again, as it will always be modified to set the swt.jar and native library path. 
the .project is actually enough to be able to 'check out as project from svn' in eclipse.
Somehow i think eclipse should be able to handle those things better tho.
maybe somthing like a 2nd .classpath for the user dfined entries, but what do i know 
Core-Dump said:
if more people find it inconvenient to have the .classpath checked in, we can delete the .classpath from svn again, as it will always be modified to set the swt.jar and native library path. :|
the .project is actually enough to be able to 'check out as project from svn' in eclipse.
Somehow i think eclipse should be able to handle those things better tho.
maybe somthing like a 2nd .classpath for the user dfined entries, but what do i know :)
Leave it in because it successfully stores the paths to the libs you distribute with the project. I only wanted to 'fix' this because I'm uber lazy. :)
Core-Dump said:
Somehow i think eclipse should be able to handle those things better tho.
maybe somthing like a 2nd .classpath for the user dfined entries, but what do i know :)
Well it does. There is no need to change the .classpath in a local environment. I dont think that someone would introduce new features, that need new libraries, without checking in those dependencies. So why would you want to change the classpath at all? If you need the SWT or anything else that might be in different locations (like the JRE), eclipse has the concept of user libraries. But for the SWT, there is already such a thing, similar to the dependencies for the JRE. I didn't try to compile the jME lately, but if there is a dependency to the SWT, there must be some kind of entry for the SWT in the .classpath (of course machine independent)