To check in, or not check in, the entire Eclipse project?

Question

I'm soon going to check in the very first commit of a new Java project. I work with Eclipse Ganymede and a bunch of plug ins are making things a little bit easier.

Previously I've been part of projects where the entire Eclipse project was checked in. It's quite convenient to get the project settings after a check out. However this approach still was not problem free:

• I strongly suspect that some Eclipse configuration files would change without user interaction (from when I used Eclipse Europa), making them appear as changed (as they were changed, but not interactively) when it's time to do a commit.
• There are settings unique to each development machine as well as settings global for all developers on a project. Keeping these apart was hard.
• Sometime if the Eclipse version was different from others Eclipse would get angry and mess up the project configuration. Another case is that it change the format so it gets updated, and if commited messes up the configuration for others.

For this specific project I have another reason not to commit the project files:

• There might be developers who prefer NetBeans which will join the project later. However they won't join within the coming months.

How do you organize this? What do you check into versioning control and what do you keep outside? What do you consider best practice in this kind of situation?

Solution 1

At a minimum you should be check-in the .project and .classpath files. If anybody on your team is hard-coding an external JAR location in the .classpath you should put them up against the wall and shoot them. I use Maven to manage my dependencies but if you are not using maven you should create user libraries for your external JARs with with a consistent naming convention.

After that you need to consider things on a plug-in by plug-in basis. For example I work with Spring so I always check-in the .springBeans and likewise for CheckStyle I always check-in the .checkstyle project.

It gets a bit trickier when it comes to the configuration in the .settings folder but I generally check-in the following if I change the default settings for my project and want them shared with the rest of the team:

• .settings/org.eclipse.jdt.ui.prefs - it contains the settings for the import ordering
• .settings/org.eclipse.jdt.core.prefs - it contains the settings for the compiler version

In general I haven't noticed Ganymede modifying files without me modifying the project preferences.

Solution 2

I recommend to use maven so that the entire life cycle is outside of any IDE. You can easily create an eclipse project with it on the command line and you can use whatever you want, if it's not eclipse. It has it's quirks but takes out a lot of bitterness when it comes to dependencies and build management.

Solution 3

In our world, we check in the entire Eclipse project and the entire parallel but separate Netbeans project. Our motivations for this were entirely focused on "when I do a checkout, I want a functional configuration immediately afterward." This means that we had to do some work:

1. Create runnable configurations for each primary IDE (people like what they like). This includes main class, working directory, VM parameters, etc.
2. Create useful start up scripts for all of our relevant scenarios.
3. Create edited datasets that don't cause the checkout to take too much longer (it's a big project).

This philosophy was worth cash money (or at least labor hours which are almost more valuable) when our new hire was able to check out the project from Subversion into Eclipse and immediately run a functional system with a (small) real data set without any fuss or bother on his part.

Follow up: this philosophy of "make the new guy's life easier" paid off again when he changed IDEs (he decided to try Netbeans after using Eclipse for quite a long time and decided to stick with it for a while). No configuration was required at all, he just opened the Netbeans project in the same directory that Eclipse had been pointing to. Elapsed switchover time: approximately 60 seconds.

Solution 4

I only ever check in things are done by humans, anything else that is generated (whether automaticly or not) should be easy to regenerate again and is liable to change (as you've stated). The only exeption to this is when the generated files are hard (requires alot of human intervention ;) ) to get it right. How ever things like this should really be automated some how.

Solution 5

I like checking in the .project, .classpath, and similar files only if they will be identical on any Eclipse user's machine anyway. (People using other IDEs should be able to check out and build your project regardless, but that issue is orthogonal to whether or not to check in Eclipse-only files.)

If different users working on the project will want to make changes or tweaks to their .project or .classpath or other files, I recommend that you do not check them into source control. It will only cause headaches in the long run.

View more solutions

Comments

[Admin]

My suspicion came from working with Eclipse Europa. And at least it needs to store history information when editing a file (as you can do a rollback from local history). I think my problem is I don't know which files are meant for what. Thanks for your advice, I'll look into it more!

[Xairoo]

We generate the .project and .classpath since we started using maven, since this eliminates the need to keep them in sync.

[Admin]

From me too. :-) (In these subjective subjects I tend to up vote all answers who try to answer the question.)

[Admin]

And when I think more about it. It may have been the result from a buggy Web Tools Platform. And it might have been in the .settings directory. I don't have any specifics at all! :-)

[Mr_and_Mrs_D]

Official eclipse link

[Soid]

Because you don't wanna deal with merges and conflicts in automatically generated files. You won't have problems though if you're working alone or in a small team.