.settings/org.eclipse.jdt.core.prefs 是项目的一部分吗？

Is .settings/org.eclipse.jdt.core.prefs part of the project?

提问by Micha Wiedenmann

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

该文件.settings/org.eclipse.jdt.core.prefs是项目的一部分还是我个人 eclipse 配置的一部分？

Should I add it to version control?

我应该将它添加到版本控制中吗？

采纳答案by Bananeweizen

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.

是的你应该。如果此文件不受版本控制，则您无法创建同一项目的可重现构建，因为它不再是自包含的，而是取决于您的特定 Eclipse 安装及其设置。

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

注意：这一切还需要您在项目属性中实际配置所有与 Java 相关的设置。如果您想拥有自包含项目，切勿使用 Window -> Preferences 下的 Java 编译器设置。

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

举一个具体的例子：如果你已经将你的项目编译器合规级别配置为Java 6，因为你使用的是Java 6特定的特性（比如接口上的Override annotations），那么该项目会在其他人的机器上产生很多编译错误. 这是因为每个 Eclipse 工作区中的默认编译器合规性级别是 Java 1.5，而在 Java 1.5 中根本不允许 Override 注释。

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

如另一个答案所示，这与您是在开发封闭源代码还是开放源代码没有任何关系。

回答by kostja

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.

与@nitind 的意见相反，不。您不应将任何特定于 IDE 的设置置于版本控制之下。除非您正在开发 IDE 功能或插件。

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.

如果您确实有强制性的团队范围的 IDE 设置，将它们置于版本控制之下将是一个好主意，但 IMO 具有强制性的团队范围的设置本身并不是一个好主意。

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.

对于所有其他情况，共享 IDE 设置对可移植构建不利，即使使用相同的 IDE，而且对于其他 IDE 的用户充其量也无用。

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.

编辑：我应该区分，具体取决于您项目的目标群体。如果您在使用 Eclipse 的团队中开发闭源产品，那么将这些首选项保持在版本控制之下是有帮助的，也是一个好主意。如果你正在开发一个库，封闭的或开源的，或者一个开源项目，我认为忽略偏好更合适和礼貌。

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

EDIT2：恐怕@Bananenweizen 误解了我想说的话。

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.

我知道这些设置是 eclipse 编译器设置。它们仍然是特定于 IDE 的，因为它们不会对 Netbeans 或 IntelliJ 产生任何影响，因为它们不会对来自命令行的 ant 或 maven 构建产生任何影响。

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 中为您带来许多红色波浪线。它不会，如果它是一个设置了源代码级别的 maven 项目，我不确定 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.

Eclipse 不是自己构建项目 - 如果它是 eclispe 或 ant 项目，它会使用 ant 构建它们，或者如果它是 maven 项目，则使用 maven 构建它们。ant 和 maven 对不依赖于 IDE 的源版本都有特定的设置。

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.

编辑 2020.03.15@howlger 告诉我，这些以前 eclipse 专有文件的可用性得到了改善。它们可以在 VSCode 和 IntelliJ 中使用。这提高了它们在 IDE 中有用的机会，并可能改变您共享它们的决定。

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.

IMO，这些文件令人担忧。虽然我支持将源代码级别和代码格式化作为构建的一部分，但我认为问题突出显示规则、保存操作和类似问题超出了范围。如果可能，我将它们分开，通过将它们放入构建定义来共享前者，而不是后者。

回答by J.P.

Here is the problem with putting it under version control.... If you import and open a project, Eclipse insists when IProject.open(...) is calledon touchingthe file in the .settings folder... and this is before you can register the team provider on the IProject object. That means validateEdit won'tfire 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.

这是将其置于版本控制之下的问题......如果您导入并打开一个项目，Eclipse 会坚持在 IProject.open(...) 调用时触摸.settings 文件夹中的文件......这是在您可以在 IProject 对象上注册团队提供程序之前。这意味着 validateEdit不会触发，并且无论您在弹出窗口中单击“是”还是“否”，询问“您想使其可写吗？”都会遇到烦人的错误。对于乐观的文件锁定提供者来说，这一切都很好，但对于“悲观”的提供者来说就没那么好了。对我们来说，这只是另一个日食烦恼。

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

如果由我决定，我无法将这些放在源代码管理中。

回答by Vivit

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 slidesfrom EclipseCon Europe 2015by Aurélien Pupier @apupier(Senior Software Engineer, Eclipse specialist).

答案是肯定的，在这里您可以找到它的动机和正确的方法：观看演讲“提交 IDE 元文件：误解、误解和解决方案”。或查看来自EclipseCon Europe 2015的相应幻灯片，作者是 Aurélien Pupier @apupier（高级软件工程师，Eclipse 专家）。