What files should be added to SVN in an eclipse Java project?

Question

I have a Java project I'd like to commit to my SVN repository, created with eclipse.

Now, what files (aside from the source code, obviously) are necessary? In the workspace root, there is a .settings folder with many files and subfolders, and inside the project folder there are two files - .classpath and .project, and another .settings folder with a single file - org.eclipse.jdt.core.prefs.

Which of these files should be committed to SVN and which can be safely excluded?

Answer 1

They're all useful if you want to have consistent settings across your team.

.classpath and .project mean everyone can get up and running with a project just by importing it. Any changes to the libraries and source files included in the project will be picked up by everyone when they're checked in.

The .settings directory has things like code formatting options and what the compiler considers as warnings, errors, or OK. For consistency, I've started checking these in as well (as long as everyone on your team can agree to a standard for formatting, I guess).

I've found that the biggest limitation in sharing things across version control in Eclipse is in the library definitions. Library definitions seem to be only stored on a per-user basis, so if you reference a "library" in the .classpath file, every other user has to manually define the contents of that library (or manually import your exported library definitions file).

---

Edit: (Addressing @mliebelt's comment below)

You'd only commit .settings files if you're trying to keep consistency/standardisation between developers. If that isn't an issue for the project, then not committing .settings files is one less thing to worry about maintaining. Files that are specific to an individual's favourite plugin(s) probably don't need to be committed either (although I don't think it would hurt if they were, would probably be ignored?).

The two most common ones I've found worth committing are org.eclipse.jdt.core.prefs and org.eclipse.jdt.ui.prefs , which are core to any (Java) Eclipse project.

Answer 2

You can exclude the .settings folder, but the .project file will be useful to other developers who want to reconstruct the same exact Eclipse project. If you examine the file it should only have relative references (if it doesn't, you should modify it as such.)

Answer 3

In contrast to the other answers I've made better experiences with not checking in the .project file in large open source projects that I work with.

You may disagree with me, but there is one problem with shared .project files: They contain references to the project natures used in the project. The project natures again depend on the plugins installed on the local developers machine.

Example: If you use Findbugs on a Java project, a new nature gets added to your Java project. Checking that file in, modifying it on another system (with no Findbugs installed) and afterwards using it on my system again has led to the Findbugs reference being lost for me (and therefore all Findbugs checks being removed silently).

But if you can have all of your developers agree on using the same tools, then you may be able to work around this problem easily.