Is it a good practice to include Eclipse project files in with sources in SCM?

Question

We have a rather complicated multi-module Maven project. There are Flex modules, GWT modules, Java modules, and a number of WAR modules. In order to simply the process of importing these projects into Eclipse, historically we have included all the relevant Eclipse project files in the source tree.

However, this has been a source of problems in the past because sometimes those files are modified accidently and checked in...thus causing problems for other developers. With the advent of M2E and its new support for configurators to help set up Eclipse projects upon import, we are rethinking this strategy.

In general, do projects include these Eclipse files in Subversion/Git/etc?

Answer 1

Top level answer: That's totally a matter of taste :-)

Personally, for "internal" projects (you have some control over the other developers' environments), I do include the Eclipse files, with the caveat that you have to be sure everyone uses relative paths in their configurations. (Every few months we'd have a build break because a library path was hard-coded. It took seconds to fix, but was annoying.) I also have typically made a lot of use of things like Eclipse code-formatting and compiler warnings settings to make life easier (e.g. no huge Subversion check-ins because someone's editors got into a fight over formatting tabs).

As a bonus, when you bring on a new developer, the Eclipse Subversion check-out system will auto-configure the project when it detects the .project files in your trunk/branch. This is a double Win if you use Eclipse to manage your build (as opposed to, say, Ant or Make).

If you're on a more diverse team (e.g.: not homogenously(sic?) using Eclipse), they aren't "much" of a nuisance, in practice. I have one "collaborative" project that I work on that has a folder full of MicroSoft Visual Studio control files and a .project file, and they have to be kept in sync ad-hoc, but at least there are "only two" sets of those files to sync up. Without them in Subversion, there would be one-per-developer…

I've heard of using a "dummy project" to hold project files, as well. e.g.

svn://someplace.nn/projects/MyProject/trunk —> source
svn://someplace.nn/projects/MyProject.control/trunk —> project control files

The only place I've seen that was in a project with a large GPL branch and a small repository of non-GPL local, proprietary plug-ins … the GPL branch didn't have .project files, as most of the 'Net collaborators were not using Eclipse, the project files were on the internal (private) Subversion server, and a third project contained the proprietary plug-in code. (And a fourth for art, a fifth for music…)

Answer 2

I personally don't recommend including your project config files in your SCM. The .project file contains the relative or absolute path, or URI, which can very from user to user. Specifications for the .project file can be found here.

Answer 3

Pretty much all of the (work) projects I've come across store the .project files in an SCM. Mainly for the reason that builders etc are stored in the file. So all of the developers have a consistent configuration in Eclipse.

Imagine the scenario that you're all using Checkstyle apart from one developer, who insists on putting tabs in his files :-).

It doesn't just apply to .project, but .classpath, .checkstyle, everything in .settings.

The only thing you have to be careful of is that everything that you refer to in your projects has a path relative to the project, for instance your checkstyle configuration. This means that everything you use will probably be in the SCM as well. But this is an advantage, because this is all part of your process right?

The above doesn't necessarily apply to FOSS projects, because of the diversity of IDEs used.