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 :
Related Whitepaper:

Software Architecture

This guide will introduce you to the world of Software Architecture!

This 162 page guide will cover topics within the field of software architecture including: software architecture as a solution balancing the concerns of different stakeholders, quality assurance, methods to describe and evaluate architectures, the influence of architecture on reuse, and the life cycle of a system and its architecture. This guide concludes with a comparison between the professions of software architect and software engineer.

Get it Now!  

Leave a Reply


× eight = 72



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy
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.

Sign up for our Newsletter

20,709 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books