Senior Java developer, one of the top stackoverflow users, fluent with Java and Java technology stacks - Spring, JPA, JavaEE. Founder and creator of http://computoser.com and http://welshare.com . Worked on Ericsson projects, Bulgarian e-government projects and large scale recruitment platforms. Member of the jury of the International Olympiad in Linguistics and the Program committee of the North American Computational Linguistics Olympiad. Bozhidar is a DZone MVB and is not an employee of DZone and has posted 82 posts at DZone. You can read more from them at their website. View Full User Profile

What to do with IDE project files

08.24.2011
| 8660 views |
  • submit to reddit

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

Published at DZone with permission of Bozhidar Bozhanov, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Andrew Spencer replied on Thu, 2011/08/25 - 7:26am

Yes, it's not a very exciting issue, but it's an important one because of the potential for losing time over it.

Your points are well made. I agree in principle with everything you wrote, but in practice I have one reservation. I'm not sure it's practicable to distinguish project files that represent essential settings, from those that represent mere preferences. Partly because I suspect some project files are a mix of the two, but mostly because I don't believe most developers have the motivation and attention to detail required to analyse every individual Eclipse file and take a sensible decision upon each one.

Still, at least I'll know what to do on my next project, in the event that I do feel like cleaning up after my colleagues.

Gil Tzadikevitch replied on Thu, 2011/08/25 - 2:53am

I find it much easier to use Maven to configure our projects.
Since Maven is a cross IDE configuration and is supported by all the popular IDEs, it only makes sense to commit it to SCM. When ever a user checks-out the code, he simply creates a new project based on the maven pom configuration files (making the IDE create local configuration files that are not synced to SCM).
This allows our team to use both Eclipse and Intellij with out the need for Cross IDE imports.

Gil

Christian Kulen... replied on Thu, 2011/08/25 - 3:43am

Netbeans Maven integration is in most situations configuration file free.

Russel Winder replied on Thu, 2011/08/25 - 7:26am

Gradle (http://www.gradle.org) allows you to generate the Eclipse or IntelliJIDEA project files from the Gradle specification file, so gives an way of allowing individuals to use what development tools they want, how they want, but with there being a single definition of the project dependencies, etc. I suspect NetBeans, CodeBlocks, etc. are not yet supported, but it should be easy enough to create plugins to support them.

Jagannathan Asokan replied on Thu, 2011/08/25 - 8:30am

Maven is the simple answer.

Get the latest code and run a mvn command, bingo, you are up and running irrespective of the IDEs like Eclipse, NetBeans, Intellij.

Personally, i won't prefer to check-in the .project, .classpath files of Eclipse (which i'm using currently) to the Source Control tool.

 

Eyal Golan replied on Thu, 2011/08/25 - 10:02am

As said above. Maven is the answer. With maven you can build in your command line the eclipse project (or InteliJ if you use it), and then just import it. In eclipse (probably in other IDEs) you can import as maven project and that is all. So here's our 'one step build': Checkout the project from SVN. Go to eclipse and create (import) a maven project with direction to the pom location. that's it. (well, it;s a 'two step build' if you consider the SVN download...)

Bozhidar Bozhanov replied on Thu, 2011/08/25 - 2:00pm

Alas, maven is not enough. Since my last 5 projects were using maven, I have pretty much wrote it in the light of maven. It is a huge improvement, but not always enough. I updated the post to clarify that.

Bozhidar Bozhanov replied on Thu, 2011/08/25 - 2:06pm in response to: Andrew Spencer

I have to agree with your scepticism about motivation to analyize the files and decide which one to commit. That's why it's best if a handful of poeple - team leads for example - to to that. The "regular developer" should simply checkout & run.

Loren Kratzke replied on Fri, 2011/08/26 - 12:43am

Not to beat the IDE drum, but that would be an Eclipse issue. Netbeans+Maven=zeroConfigFiles. Full disclosure: If you have multiple servers configured then NB might create a small XML hint snippet indicating your preferred server to avoid popping a dialog every time you deploy, but that file is entirely optional/avoidable/ignorable/disposable.

One exception I would make is that you can put IDE hints in a Maven pom file. These are inert to the project and are only recognized by particular IDEs (at least Netbeans has this capability, not sure about Eclipse and others).

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.