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

Posted 2023-02-19

【中文标题】.settings/org.eclipse.jdt.core.prefs 是项目的一部分吗？

【英文标题】：Is .settings/org.eclipse.jdt.core.prefs part of the project?

【发布时间】：2013-04-02 09:22:56

【问题描述】：

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

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

【参考方案1】：

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

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

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

编辑：我应该根据您项目的目标群体进行区分。如果您在使用 eclipse 的团队中开发封闭源代码产品，那么将这些偏好设置在版本控制之下是有帮助的，也是一个好主意。如果您正在开发一个库、封闭源代码或开源项目，或者一个开源项目，我认为忽略这些偏好更合适且更有礼貌。

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

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

是的，将这些设置排除在版本控制之外可能会在不同机器上的 Eclipse 中为您带来许多红色波浪线。不会的，顺便说一下，如果它是一个有设置源级别的maven项目，我不确定ant。

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

这就是这些设置应该位于的位置 - 在构建文件中。并且构建文件应该在源代码控制之下。我之前提到的例外情况仍然适用。

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

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

【讨论】：

实际提到的文件控制项目的代码合规级别和编译器错误/警告设置，例如是否/如何报告未使用的本地、私有成员、未使用的导入类或未处理的空值。这与格式样式无关，而是关于您希望为从事该项目的任何人强制执行基本的编译器可检测质量的严格程度。编辑：这个文件特别存在只是因为您选择覆盖项目属性页面中的工作区默认值。编辑：除非你使用 Facets。

@nitind - 是的，你是对的，它不像我想象的那样片面。请查看编辑

您的帖子显示了一个误解：这些不是 IDE 特定的设置。它们可能采用特定于 IDE 的格式，但它们是必不可少的项目内容，就像众所周知的类路径一样。

@Bananeweizen - 请放心，这不是一个误解，这是一个意见:) 请查看编辑。

@Bananeweizen - 顺便说一句，“这些不是特定于 IDE 的设置。它们可能是特定于 IDE 的格式”是完全错误的——这些设置只能由 eclipse IDE 应用，因此它们是 IDE-具体的。也许您想说它们实际上并不是打算特定于 IDE，但遗憾的是它们是，这就是我的观点。

【参考方案2】：

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

如果您将此项目导入另一个工作区（在您或任何其他机器上），它的行为可能会完全不同，因为编译器合规性设置、编译器警告配置和许多其他内容突然丢失或不同。这样的项目很有可能突然在新工作区中显示警告/错误，而之前完全没问题。

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

举个具体的例子：如果您已将项目编译器合规级别配置为 Java 6，因为您使用的是 Java 6 的特定功能（例如覆盖接口上的注释），那么该项目将在其他人的机器上 create a lot of compile errors .这是因为每个 Eclipse 工作区中的默认编译器合规级别是 Java 1.5，而在 Java 1.5 中根本不允许 Override 注释。

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

【参考方案3】：

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

如果由我决定，没有办法我会把这些放在源代码管理中。

【参考方案4】：

答案是“是”，在这里您可以找到这样做的动机和正确的方法：watch the talk“提交 IDE 元文件：误解、误解和解决方案。”或查看 Aurélien Pupier @apupier（高级软件工程师，Eclipse 专家）的 EclipseCon Europe 2015 中对应的 slides。

【讨论】：

“链接很棒，但它们绝不应该是您答案中的唯一信息。”。见meta.stackexchange.com/questions/8231/…