34

Is the file .settings/org.eclipse.jdt.core.prefs part of the project or is it part of my personal eclipse configuration?

Should I add it to version control?

Micha Wiedenmann
  • 19,979
  • 21
  • 92
  • 137

4 Answers4

30

Yes, you should. If this file is not under version control, then you cannot create reproducable builds of the same project, because it is no longer self contained, but depends on your specific Eclipse installation and its settings.

If you import this project into another workspace (on your or any other machine), it may behave completely different, as the compiler compliance settings, the compiler warnings configuration and a lot of other stuff is suddenly missing or different. Chances are high that such a project suddenly shows warnings/errors in the new workspace, while it was completely fine before.

Note: This all also requires that you actually configure all Java related settings in the Project properties. Never use the Java compiler settings under Window -> Preferences if you want to have self contained projects.

Just to give a concrete example: If you have configured your projects compiler compliance level to Java 6, because you are using Java 6 specific features (like Override annotations on interfaces), then the project will create a lot of compile errors on other peoples machines. This is because the default compiler compliance level in every Eclipse workspace is Java 1.5, and in Java 1.5 that Override annotation is simply not allowed.

This doesn't have anything to do with whether you are developing closed source or open source, as indicated in the other answer.

Community
  • 1
  • 1
Bananeweizen
  • 21,797
  • 8
  • 68
  • 88
19

Contrary to @nitind's opinion, no. You should not put any IDE-specific settings under version control. Except you are developing IDE features or plugins.

In case you really have mandatory team-wide IDE settings, putting them under version control would be a good idea, but IMO having mandatory team-wide settings is not a good idea in itself.

For all other cases, shared IDE settings are bad for portable builds, even with the same IDE, and useless at best for users of other IDEs.

EDIT: I should differentiate, depending on the target group of your project. If you are developing a closed source product in a team that works with eclipse, then keeping these preferences under version control is helpful and a good idea. If you are developing a library, closed or open source, or an open source project, I consider ignoring the preferences more appropriate and polite.

EDIT2: I'm afraid @Bananenweizen is misunderstanding what I am trying to say.

I know that these settings are the eclipse compiler settings. They are still IDE-specific in the sense that they won't have any effect in Netbeans or IntelliJ as they won't have any impact on ant or maven builds from the command line.

Yes, leaving these setting out of version control can bring you many red wavy lines in eclipse on a different machine. It won't, if it's a maven project with a set source level by the way, I'm not sure about ant.

Eclipse is not building the projects by itself - it builds them with ant if it's an eclispe or an ant project, or with maven if it's a maven project. Both ant and maven have specific settings for the source version that do not depend on IDEs.

And this is where these settings ought to be - in the build file. And the build file should be under source control. The exceptions I mentioned earlier still apply.

EDIT 2020.03.15 @howlger informed me that the usability of these formerly eclipse-exclusive files has improved. They can be used in VSCode and maybe IntelliJ. This improves their chances of being useful across IDEs and may change your decision towards sharing them.

IMO, the files are mixing concerns. While I support source level and code formatting as being part of the build, I consider issue highlighting rules, save actions and similar concerns to be out-of-scope. If possible, I separate those, sharing the former by putting them into the build definition, but not the latter.

kostja
  • 60,521
  • 48
  • 179
  • 224
  • 2
    The actual file mentioned controls the code compliance level and compiler errors/warnings settings for the project, such as if/how to report unused locals, private members, unused imported classes, or unhandled nulls. It's not about formatting styles, it's about how rigorously you want to enforce basic compiler-detectable quality for anyone working in that project. EDIT: this file in particular exists only because you chose to override the workspace defaults in the project's property page. EDIT: unless you're using Facets. – nitind Apr 10 '13 at 15:21
  • @nitind - Yeah, you're right, it's not as one-sided as I thought. Please see the edit – kostja Apr 10 '13 at 19:52
  • 2
    Your post shows a misconception: Those are not IDE specific settings. They might be in an IDE specific format, but they are an essential project content, just like the well known class path is. – Bananeweizen Apr 11 '13 at 06:44
  • @Bananeweizen - Be assured, it is not a misconception, it's an opinion :) Please see the edit. – kostja Apr 11 '13 at 08:23
  • @Bananeweizen - btw, "Those are not IDE specific settings. They might be in an IDE specific format" is plain wrong - the settings can be applied only by the eclipse IDE, therefore they are IDE-specific. Perhaps you wanted to say that they are not actually **intended** to be IDE-specific, but sadly they are and that's my point. – kostja Apr 11 '13 at 09:22
  • Agreed. It's sometimes hard to get such things converted to English without loosing the intention. Basically I wanted to say those settings should be shared (and should be IDE independent) like the classpath setting is, but sadly there is no common format. – Bananeweizen Apr 11 '13 at 12:49
  • @Bananeweizen - then we agree on the causes and disagree on the consequences. Thats alright with me. – kostja Apr 11 '13 at 13:23
  • @kostja The Eclipse compiler preferences file is used by Eclipse and VSCode. AFAIK it can also be used in IntelliJ which is shipped with the Eclipse compiler. The Eclipse batch compiler can also be used in a build as linter to create problem reports. Independent of this, tool-specific project settings should be shared as long as they are used and maintained. A build file is only about to get the dependencies and how to build it. It does not say how to format your code, which problems should be displayed, which save actions should be applied, etc. – howlger Mar 14 '20 at 15:42
  • @howlger - ah, good to know that these files are now usable across multiple IDEs. This was not the case at the time of my answer. This does make a differerence. However, I still think that IDE-related issue highlighting rules and save actions are a personal preference rather than a project setting. They might be helpful in collaborating, but are orthogonal to the project itself. There are other build systems with IDE-independent formatting rules, e.g. sbt. I prefer to use these instead of IDE-specific ones. – kostja Mar 15 '20 at 11:47
  • @kostja VSCode is new, but the other ones already existed then (at least I used the Eclipse compiler to create reports in nightly builds already in 2005). In Eclipse you can decide whether the compiler settings should be project-specific or user-specific. The file exists because the decision was made for project-specific. The answer claims _"IDE settings are bad for portable builds"_, but sharing this file is not against IDE agnostic builds. This is still misunderstood by many. These days it's common sense to share tool-specific configuration files as long as they are used and maintained. – howlger Mar 15 '20 at 13:51
  • @howlger. I am differentiating - using IDE settings **for settings which should go into the build file as well as personal preferences** is bad or at best irrelevant for portable builds. I have said so twice in the answer. I have seen IDE-specific files hinder collaboration bc of this this. Situations exist where sharing those still can be helpful, yes. Anything more is a question of personal preference. – kostja Mar 16 '20 at 15:01
2

Here is the problem with putting it under version control.... If you import and open a project, Eclipse insists when IProject.open(...) is called on touching the file in the .settings folder... and this is before you can register the team provider on the IProject object. That means validateEdit won't fire and you get annoying errors whether you click "yes" or "no" on the popup asking "do you want to make it writeable?" That's all well and good for optimistic file-locking providers, but no so great for the "pessimistic" ones. For us this is just been yet another eclipse annoyance.

If it's up to me, there is no way I'd put these in source control.

J.P.
  • 21
  • 1
1

The answer is "yes" and here you find the motivation for it and the proper way to do it: watch the talk "Committing IDE meta files: misconceptions, misunderstandings, and solutions." or look at the corresponding slides from EclipseCon Europe 2015 by Aurélien Pupier @apupier (Senior Software Engineer, Eclipse specialist).

Software Craftsman
  • 2,999
  • 2
  • 31
  • 47
  • 1
    "Links are fantastic, but they should never be the only piece of information in your answer.". see https://meta.stackexchange.com/questions/8231/are-answers-that-just-contain-links-elsewhere-really-good-answers – Micha Wiedenmann Feb 21 '18 at 14:47