Should I commit files that are changed by Eclipse?_问答_开发者

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?

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).

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.

It is better not to commit those files as paths/settings may differ on different workstations.

You may wanna use some build tool to overcome this. (eg. Maven)

As if any of the team members are not using eclipse (using some other ide) , those files have no meaning for them.

If everyone commits different IDE settings, imagine what kind of mess it can cause.

EDIT:

More explanation;

I have worked in teams that people used NetBeans, Eclipse, IDEA...for a really long time and it is not really an option for them to change the IDE. It will only affect the productivity of that person.

When people get used to their IDEs they learn shorcuts, they know where to look for some functions (refactor/generate getter setter/implement override required methods....) so if you force them to use some other IDE it will just make things harder for them and slower for the overall process. IMHO and from my experience having a flexible codebase is always good. I am an eclipse guy and probably would not want to work with any other IDE as I know lots of shorcuts which makes thing real quicker/easier for me and those shorcuts are different on different IDEs.

All IDE files can be regenerated automatical by the IDE itself probably in just a couple of clicks.

And my current project has 3 developers, each using different IDEs eclipse(me), NetBeans, IDEA without any problems. I dont want to see IDEA or NetBeans config files which makes no sense for eclipse when I check out the source from repo. Likewise for them as well.

Yes, though do make sure that paths are relative in the workspace rather than absolute paths. Having these files in the workspace allows members of your team to work in the same environment as you are. It also makes setting up a new development environment much easier: you just check it out of source control and in Eclipse use 'Import... > Existing Projects into Workspace'

As @adamdunne mentioned, these files can contain environment specific paths. However it if you are careful to make sure paths are relative within your workspace, by using variables and by not importing external jars, i.e., by only including jars from projects in the workspace, then you should be okay. In my workspace we check in those files and have had a lot less issues setting up dev. environments since.

I work in a project where we commit the .classpath file since it is very useful that all developers use the same :) If you only use dependencies inside your workspace, this file uses relative paths and thus should be same on all machines. Even if this file might not be necessary to build (with ant e.g.) it´s very convenient to synchronize it.

In contrast the org.eclipse.core.prefs stores (afaik) project-specific, but personal preferences of developers which I would not check in.

With the facets I didn´t work yet in a real project, so I can´t tell. But in general, I think it depends on the information in the file and on the way you work.

If you are unsure, just try it. If you get conflicts in these files all day this is a hint you may not be on the perfect way.

These files can be very useful to share configurations between developers. The alternative is to either use Maven (which is a huge task for an established project) or to have constantly-outdated step-by-step instructions and new developers taking half a day until they can even build the project.

However, you should take care to ensure that these configurations are portable, i.e. contain no local paths. This can be done via the use of relative paths within the workspace, eclipse path variables and user libraries.

What we've done is ignore these files, as they may mess up the workspace of others on the project.

Ignoring them also makes your project cleaner, which I always like.

These files can contain environment specific paths so I would suggest not checking them in. On my current project we use ant scripts to create the project and do the initial checkout of all our code.