views:

256

answers:

6

I'm running an open source java project that consists of multiple modules in a tree of dependencies. All those modules are subdirectories in a subversion repository. For newcomers to our project, it's a lot of work to set all that up manually in eclipse.

Not all our developers use eclipse. Nevertheless, we're considering to just check in the .classpath and .project files to help newcomers to get started. Is this a good idea? Or would that lead to constant conflicts in those files? Is there an alternative way to make the project easy to set up on eclipse?

+2  A: 

Definitely no - it's generally terrible idea to distribute project files via subversion. Especially since someone might modify them in a some strange manner. A good page in the project's documentation is a much better idea. Our project also has many modules and a complex setup. We've set up a confluence page describing how to get started with the project on each populer IDE - IntelliJ, Eclipse, NetBeans. A README file in Subversion contains the same info.

Bozhidar Batsov
I can't agree. From my experience it is good to check theese files in to make the checkout as easy as possible. Someone might change them in some strange manner? Someone might change your code in some strange manner ...
Arne
Arne, you should make that an answer, not a comment.
amarillion
The project files for any IDE are not actually part of any project - if you want to distribute them - go ahed - attach them to the article I mentioned. Generally everyone on a team can modify the files in the repo, but not everyone can attach new files to important documentation nodes, etc. It's very easy for someone to forget to ignore the classpath and project files and commit them when he shouldn't. Even if you keep them in subversion - you should certainly keep them somewhere on the side...
Bozhidar Batsov
-1, couldn't disagree more. Projects settings are a *crucial* part of the day-to-day work with a project. The disadvantages of accidentally checking in wrong settings are much smaller than the advantages of automatically keeping everyone up to date. After all, you can always easily go back to previous versions.
Michael Borgwardt
Everyone is entitled to an opinion. As a matter of fact I'd never create a project relying on Eclipse's(or any other IDE's) project system in the first place... Maven is the ultimate project comprehension tool and renders IDE specific setups obsolete. Btw the time to notice that something is wrong with the current settings and go back to previous revision is unlikely to differ from the time to adjust any new settings yourself. At least in my company everyone on the team gets notified via e-mail if some user intervention is required after bigger changes.
Bozhidar Batsov
+2  A: 

I would check theese files in to make the start for new users as easy as possible. At best the user should check out the project and should be able to run it without extra knowledge. For this files the rules are the same as for other files in the project: handle them with care. You should not place absolute pathes in the source code, neigther you should in the configuration files.

If the files are checked in in a way that the project runs from scratch there should not be much forces to change them.

Arne
+1  A: 

I would recommend that you check the files into subversion IF they do not contain absolute paths and other data which would tie them directly to a single developer's environment.

If the files do contain absolute paths and the like, a README would be a better choice.

vkraemer
+1  A: 

Yes, definitely check them in, but make sure that you document any path dependencies and avoid absolute paths if possible.

If you don't check them in, then anyone checking the project out will need to recreate all of those settings, which is annoying and potentially error prone.

Some complex setups may be better handled by a script to generate these files, but usually it is better to just check them in.

Christopher Barber
+5  A: 

Definitively yes, as I said in "Do you keep your project files under version control?"

"Load it up, set it up, go."

But... this is actually true only for recent Eclipse3.5 settings, where build paths support relative paths:

alt text


And Eclipse3.6 would be better, as it supports relative paths for Linked resources.

alt text
(since 3.6M5)

VonC
Wow, I didn't know they added this... Would have saved us some grief
Uri
+1  A: 

I vote no, but that's because I would generally generate these files from maven

Rulmeq