See Stop adding Eclipse .classpath and .project files to cvs! for part 1.
Too many reactions, so I guess I need to show the problems I am facing and react to some of the feedback I got.
- I am not a team player, since I don't work the same way as other people (this was sarcasme, but deserves an answer :)
I do work differently indeed and maybe I am not the perfect team player. Since I invest a lot of my time working (more than the required 40 hours a week), I want some satfisfaction in doing "extra" things that makes me happy or things I find challenging. My project xulux is an extension of this extra work that I like and also me running under linux instead of windows
I tend to do things my way, unless someone shows me things that are better (eg scalebility, easy deploy process, release management, etc). Maybe I don't deliver these kind of things as a team, but it saves me a huge amount of usefull time.
- One thing I heard "Use classpath variables". We do now. So in most scenarios this won't be a problem anymore, but since we just type maven eclipse in the project, we don't want the .classpath and .project in cvs anyway :)
- Create a new project, commit the whole buch in cvs (including .classpath and .project). Let's assume this projects depends on velocity 1.3. I want to know if this stuff also works with 1.4-dev . I update the classpath to 1.4 and update again to use 1.3. My .classpath has changed! Even though everything is the same as it was. You say Ohh simple, just go to the resource view, right mouse button Team, Replace With Latest from repository. The resource view is not on sync with the java view, so the focus is not on the project and I have to find it manually. If I or my co-workers accidentily commit the newly set dependency we potientially have a problem or have to restore the latest .project (eg if I just added a nature to experiment with aspects) and .classpath.
I think it is best to seperate concerns. Development is also experimenting with new dependencies, other dependencies, setting project dependencies (we have about 30 seperate projects that make up our system) and you don't want those two to get mixed up. Nothing is worse than someone who by accident commited the .classpath and .project and you have to update the project and end up with conflicts in those files and this way undermine my personal settings for the development session I am currently in (eg debugging, profiling, testing, experimenting).
- I also read that someone uses the .classpath in ant to build the dependencies in ant. That's cool as an experiment, but I think the process should be the other way around : let Ant be able to drive eclipse in this respect. Not critizing the choice he made, since it seems to work great for him. Development is a completely different task then building for eg testing, releasing, etc. Development, testing and releasing often require different dependencies (developing against the latest snapshot, testing against that snapshot AND the stable release of that project and always releasing against stable releases of dependencies. Using eg mavens project.xml as the release dependency and the eclipse as the development dependency seperates these concerns in our / my scenario.
- Using mevenide was also mentioned. Since I am the initial founder of the project, which I was dead right away since I had too little time to do some serious work on that (btw MIlos & Gilles are doing a great job!) Mevenide is to be able to integrate (maven) project management in an IDE. Still you need to clearly seperate concerns here and eg have options to not automatically roundrtip changes from project.xml to .classpath and .project and especially not the other way around. It would be, at least in my vision, be bad practice for mevenide to immidiately change the project.xml or your .classpath without me knowing it after updating.
So mevenide should let the developer stay in control on what choices he/she makes during development (not saying here it doesn't though).
- The comment that not checking in the .classpath and .project files is just like not checking in the ant build.xml. I wrote enough already to make clear why I don't think these files are the same.
Als mentioned is that I should add libraries to cvs, which in my view is bad practice.
- Prashant Rane mentiones a nice solution or at least put me on track of a possible one. Adding to a cvsignore file is not an option though, since that file is already in cvs most of the time (eg the standard *.log excludes) and adding the .classpath and .project files to that file will have the result that the files will be ignored for everyone (like that since that is what I want).
Tried Window/Preferences/Team/Ignore Resource and added .classpath and .project there.. But that only works for resources not yet in cvs, so though luck for me :(.
- Where does this end ? Does everyone also put jar descriptions in cvs so they can build jars with eclipse and release that way, add eclipse launchers to cvs, etc ? (we all had that btw :)
This is getting rather a long episode and if you don't already agree with me, you probably will not in the future, but I hope you better understand my motives for not wanting those files in cvs.. The discussion goes way beyond some open source projects adding those files though (normally they tend to be more aware of what tools do and how they work and are more carefull committing bad things and this way cause less trouble than coorperate projects).
But I still hit the same issues and that is that my development settings get tampered with, without me actually wanting that.
Don't get the wrong impression : I love using Eclipse.. (afaik eclipse itself has .project and .classpath files in cvs and it seems to work ok for them too).
Maybe someone at eclipse itself can enlighten me :).