Bozhidar Bozhanov

About Bozhidar Bozhanov

Senior Java developer, one of the top stackoverflow users, fluent with Java and Java technology stacks - Spring, JPA, JavaEE. Founder and creator of Computoser and Welshare. Worked on Ericsson projects, Bulgarian e-government projects and large-scale online recruitment platforms.

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.

Reference: What to do with IDE project files from our JCG partner Bozhidar at the Bozho’s tech blog.

Related Articles :

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

Leave a Reply


3 × = fifteen



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close