Should I commit files that are changed by Eclipse?

Question

I inherited a Java project in the form of an Eclipse project. After changing the Tomcat configuration (from v6 to v7), Subclipse prompted me to commit the following files:

• .classpath
• org.eclipse.core.prefs
• org.eclipse.common.project.facet.core.refs
• org.eclipse.common.project.facet.core.xml

Will commiting them help my team members or will it mess with their workspace?

What is the best practice approach to this?

Answer 1

Generally speaking, you should check-in (and commit after changes) everything that does contribute to the build AND is not re-generateable by re-building completely AND is workstation-specific. (The implications of this statement depend on your build process/procedure, which is intended.)

This implies you should exclude everything that is re-generated upon full build etc. so it is not checked in (and not offered for check-in).

Answer 2

As a general rule, you should avoid committing files that contain user preferences, and project details that that Eclipse and/or your plugins can regenerate.

But in some cases things are a bit murky. For instance, the .classpath file can be the primary source of the Eclipse build path; e.g. if you have JAR files in your project tree rather than using Maven. (With Maven, the m2eclipse plugin generates the .classpath file from the dependency information in the POM file, and hence the file should not be checked in.)

Also, some of the facet stuff is borderline. For instance, in projects with JSPs and Javascripts, I have found it essential to change the facet properties to disable broken validators. And there's a good case for treating those changes as part of the project rather than as personal preferences.

Separation of group / project preferences from personal preferences is one area where (IMO) Eclipse is seriously deficient.