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?

Banana

See #116621, or #2024807 , or (more generic) #1881317 – Ygerne

Wow. I tried to look around a bit. I think that my question can "break" into two or three and get for each one of them proper responses. I believe the best answer would be your comment :-) – Banana

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

Amyamyas

This also implies that all the files in the question should be examined for workstation-dependent things like file paths and user preferences. And if there is nothing workstation or user dependent in some of them, then there is nothing wrong with committing that particular files. For example, .classpath may contain file system paths, but maybe it just contains workstation-independent library names and paths for them are defined elsewhere. – Barram

@Sergey Tachenov: Yes, and that's what I meant with "The implications of this statement depend on your build process/procedure, which is intended." – Amyamyas

I checked everything and saw that the files were all path independent. I thought that in the Eclipse everything would be either path independent or dependent, but not both... – Banana

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.

Moxa

Are other IDEs better, and if so, how? I think eclipse is so-so: it's great to have the essential project configurations as text files within the project directory. It's not so great to have them distributed over various files in various formats. – Bookworm

@Michael - "Are other IDEs better" - seriously, I don't know. And its probably one of those things that is too hard / too late to fix. – Moxa

Answer 3

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.

Snakeroot

+1 for the workstation-specific aspect. In return, I allowed myself to add this aspect to my own answer. – Amyamyas

"by whom? Why?" :) complete question sentence will make me understand what the question is? – Snakeroot

@fatih: OK. "This was downvoted by one -- by whom? And why?" Better? – Amyamyas

downvote was from me, because none of these (except for the reference to Maven) are good arguments for avoiding the substantial benefits of checking in these files. – Bookworm

Standardizing on an IDE or letting everyone use what they know best is a tradeoff with advantages and disadvantages on both sides. But "not wanting to see" config files from other IDEs is still a very poor reason for not having them in source control. They help the people with that IDE and are at worst a minor annoyance for everyone else. – Bookworm

Pls name a couple of advantages for forcing people use some specific IDE. As mentioned before, all IDE specific files are auto-generated and can be regenerated by IDE again easily, however it may make life easier for some who do not know how to do that in the IDE they are using but i still don't see this as a good reason to commit generated files – Snakeroot

@fatih, if the advantages are not clear by now I dunno what to say. I'll try: Using a team-widely standardized IDE allows you to agree upon the config details we just discussed. If everybody uses what he/she wants, you can prepare for repeated phases of chaos where someone (the build manager?) has to debug where what came from, and why, and what symptoms are the culprits. Of course, it might have an individual productivity advantage if one can use what one knows best. Being a fan of standardized team behavior, I'd vote for the common IDE idea. – Amyamyas

fatih, I'd add: If you standardize the IDE aspects, you can build up one "expert group" which creates the IDE config, and deploys them by checking it in. So not everybody has to find solutions to questions that we just answered. I love that. – Amyamyas

Answer 4

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.

Loss

+1 for indicating how to get rid of workstation-specific config details. – Amyamyas

We did that ( 'Import... > Existing Projects into Workspace') and this is the reason I asked the question in the first place. Currently my team is in training mode and I want to adopt as many best practices as I can for the project's life cycle. – Banana

Answer 5

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.

Groomsman

>>If you are unsure, just try it. << And let the rest of the team enjoy that experience immediately, as well, hehehe. If you get conflicts in these files all day, it is a hint that the rest of the team gets them, too, and you successfully bombed the build :) – Amyamyas

>> If you get conflicts in these files all day this is a hint you may not be on the perfect way.<< Duke Nukem would say: "Hehehehehe, what a mess." :) – Amyamyas

org.eclipse.core.prefs stores things like the Java compiler source and target versions and warning/error settings, which I would actually consider quite useful NOT to have every developer decide for themselves. – Bookworm

The comment from @Michael... Where can I find out where Eclipse stores what? – Banana

@dimitris: that's the problem... I don't think it's officially documented anywhere. But the config files are generally quite readable. – Bookworm

Answer 6

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.

Bookworm

I also wrote it in a different comment, I believed that eclipse had all paths relative or absolute but not both. This is the main reason I posted this question. Based on this and similar advices I started reviewing every file and saw what was going on in each one of them. Thanks a lot. – Banana

@dimitris: It's definitely possible to have both. For example, when adding a JAR to the project's build path (which results in an entry in the .classpath file), you have the options "Add JARs", which lets you choose a file from within the workspace and generates a relative path, and "Add External JARs", which lets you choose any file and generates an absolute path. – Bookworm

Answer 7

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.

Aguirre

I did not do that downvote, however I guess the downvoter considered "cleaner" too vague, as might be the case for "mess up the workspace". The typical so newbee situation: You try, and get bumped away. Keep going, @cgratgny, learn from it, and your point balance will explode sooner or later. Just don't get frustrated by this initial learning curve, it can be considered normal. – Amyamyas

Thanks for the comment, @TheBlastOne. I know I was trying.. just not so eloquent as others in the solutions they provide. – Aguirre

Answer 8

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.

Medrano