July 01, 2004

Stop adding Eclipse .classpath and .project files to cvs!

I am getting sick and tired of projects adding those files.
I am a big eclipse user (have 4 versions running, using different startup jdks, different development jdks, etc) and when there are .classpath and .project files in cvs and I checkout a project, immidiately I have to change those settings to get the system going. If a committer of such a project changes something to his eclipse setup or project setup, as soon as I update I have a conflict in the .classpath or .project file.
I normally check out projects in eclipse to do some debugging and change dependencies or check to see if the dependencies I would like to use for a certain project also work, so my local changes get also hosed if someone commits a change to the .classpath file or the .project file..
At work we also had this issue and I kept on fixing those 2 files. As soon as I started committing these files, everyone started complaining that their eclipse projects was messed up (couldn't find my jvm).
Some people actually use some options available in eclipse and therefore they are screwed when those files are in cvs..

Please add .classpath and .project files to the .cvsignore file!

See Part 2 : Stop adding Eclipse .classpath and .project files to cvs! for the follow-up on this.

Posted by mvdb at July 1, 2004 01:34 AM
Comments
Please close your <b> on that last line! It's messing up all of planetapache.org Posted by: Dave Brondsema on July 1, 2004 02:21 AM
Um... Eclipse is actually developed to deal with that situation. Rather then complaining about projects including these things (which make it easier for the developers to share the project around themselves), why not ask them to use things like classpath variables which you can then configure in your own system? Posted by: Robert Watkins on July 1, 2004 03:25 AM
I agree that these files should be checked in. We have many dozens of projects in CVS, and it would be ludicrous to ask people to recreate the project and library settings on checkout. There are plenty of mechanisms available so that these files stay portable. Posted by: Colin Sampaleanu on July 1, 2004 04:32 AM
Another option is to copy the .project and .classpath files to sample.project and sample.classpath and check -those- in to cvs (with logical defaults based on your typical environment, if there is such a thing). When folks check out a project for the first time, they could copy the sample file to .project and modify it from there or ignore it. Posted by: Scott on July 1, 2004 05:56 AM
PCR: a build.xml is definitely not comparable to .classpath and .project files, since by default I cannot get around the .classpath and the .project. It manages my eclipse and I like to manage my eclipse. I think I am going to look at Prashant's option to have some global .cvsignore, but I don't know if eclipse supports that.. Btw most projects I use ared mavenized and I just type maven eclipse to get the project up and running in eclipse... Posted by: Martin on July 1, 2004 09:02 AM
The concept of a sample.classpath/sample.project is the only workable solution. The assertion that one is not a team player is ridiculous, since that is not the issue. The issue being that those files are not 'visible' and the average developer never ever looks inside, and spend little or no time reflecting over what changes in the Eclipse dialog boxes will make changes to these files. HENCE, someone else makes an ignorant change (in all sincerity) everything stops working everyone else. Huge difference. For open source projects this is even more relevant, since there are no company wide policies, and no enforcements. Posted by: Niclas Hedhman on July 1, 2004 07:10 PM
Robert is right. Eclipse supports variables in the .project and .classpath files which make it possible to check those in independent of specific system configurations. The only problem is that (at least on my M7, but I haven't heard that it's been dealt with) this breaks CVS integration, since it starts treating all included files as external to the project. Oh well, that's what TortoiseCVS is for :) Regarding Joe's comment, he's right except that I don't see the sarcasm. Anyone who is not using the common development environment is either an asshole, a dumbass, or a masochist. Either way, the build will get broken. Regarding Niclas's comment, anyone who makes changes to the build without thinking about the impact on others is not an average, but a far below average developer, at least where I work. Posted by: Eugene Kagnovich on July 2, 2004 01:44 AM
Eugene: Too bad you are working with M7.. afaik M7 messed up eclipse settings pretty badly. So maybe you problem is related to that version (upgrading to m8 or higher doesn't solve the problem if you have converted from eclispe 2.1 with m7..). About your comment regarding "common development environment" : Common development environment (at least the IDE part) doesn't make all developers work at their best with default company set defaults. I work best my way and made sure we can all have the same environment when building and testing stuff (through maven). If I want to use IDEA I should be able to do that, without being bothered with maintaining an eclipse specific project format. About your last entry in your comment : People make mistakes. That doesn't make them less average. Under "stress" or hurry people sometimes commit a bit too much. Since we switched to maven that problem isn't there anymore.. Nobody is making temporary changes to the project.xml and constantly do change their eclipse dependencies.. (from jar to project dependency, etc). Posted by: Martin on July 5, 2004 02:08 PM