What to do with IDE project files

Each IDE generates its specific project/config/build files. Eclipse generates .project and .classpath, and also the .settings directory. IntelliJ IDEA has its .iml files. And it is always a question what to do with these files in terms of source control management (SVN, CVS, git, etc)

The generally accepted practice is to add them to the SCM ignore list (svn:ignore for example). Why?

• the project does not become aware of the IDE it is developed in. Each team member can use an IDE of their choice
• there is no danger of sneaking absolute path configurations into the repository
• no developer can override the local settings of other developers

This practice makes sense, but it has one major drawback – the complexity of setting up a project has to be repeated every time. In other words, you can’t start developing immediately after you checkout – you have to configure tons of things – deployment on local server, checkstyle configurations, plugin configurations, etc. Joel Spolsky insists on having a one-step build. Using a build tool instead of the IDE build process is preferable (ant, maven). But in addition to that you should also have a one-step development environment setup (apart from installing a database/search engine/etc.).

So how to do that? I know this is an unpopular advice but: commit the IDE project files in the repository. Once a member has a successful local setup, the files should be committed so that everyone else can just checkout/update, and get the project running. I’m sure everyone has gone through the trouble of helping set up the project for new team members, or when getting a fresh checkout on the local machine (due to scm bugs, OS reinstall, whatever).

Of course, you can’t just commit everything – look at the list above to see the reasons why this may be wrong. Here’s one thing to remember: never commit absolute paths. Everything must be project relative. If for some reason (for example – deployment with FileSync rather than WTP, in Eclipse) you need an external path – place it in a variable withing eclipse and use that.

As for the other two bullets from the above list – having the project files committed does not tie to project to a specific IDE. It makes it available for immediate use for that IDE. There is no problem in having .project and .iml files in the same project. It’s just that they won’t be used by everybody. But no part of the project is used by everybody anyway. About local preferences – don’t commit those. Determine what IDE files are needed for getting the project running and ignore the rest. For example, and eclipse WTP project will need the faceted project settings committed – that is “.settings/….facet.core.xml”. Having consistent formatting rules requires a .prefs file. But view settings for a BPM visualization plugin are a matter of developer preference – ignore them.

Finally, have one .txt files in the project root that describes in a few lines how to have a working environment. The aforementioned IDE variables (if needed), the required IDE plugins, installing the needed software (e.g. database), etc. But it should be minimal – after all we are trying to have an (almost) one-step development environment setup.

Update: Many people suggested that maven solves all these issues. It doesn’t. The Eclipse-maven integration, for example, is almost good enough, but not quite. You still have to perform some manual tasks. m2eclipse doesn’t allow you to deploy. m2eclipse-wtp does, but it doesn’t always work, sadly. Enabling project facets is not something maven does. And there are more. Maven is a huge improvement, but it is not enough in many cases.

From http://techblog.bozho.net/?p=470