.classpath和.project-是否签入版本控制？

我正在运行一个开源Java项目，该项目由一个依赖树中的多个模块组成。所有这些模块都是子版本库中的子目录。对于我们项目的新手，要在eclipse中手动进行所有设置，这是很多工作。

并非我们所有的开发人员都使用eclipse。不过，我们正在考虑仅检入.classpath和.project文件以帮助新手入门。这是一个好主意吗？还是会导致这些文件不断发生冲突？有没有其他方法可以使项目易于在Eclipse上设置？

绝对可以，正如我在“您是否将项目文件保持在版本控制下？ ”中所述那样。

“加载，设置，开始。”

但是...这实际上仅对于最近的Eclipse3.5设置才是正确的，其中构建路径支持相对路径：

而Eclipse3.6会更好，因为它支持路径变量相对路径中Linked Resources：

（从3.6M5开始）

绝对不能-通过Subversion分发项目文件通常是很糟糕的主意。特别是因为有人可能以某种奇怪的方式修改它们。在项目文档中写一个好页面是一个更好的主意。我们的项目还具有许多模块和复杂的设置。我们已经建立了一个融合页面，描述如何在每个Populer IDE（IntelliJ，Eclipse，NetBeans）上开始该项目。Subversion中的自述文件包含相同的信息。

我投不赞成票，但这是因为我通常会从Maven生成这些文件

以我的经验，不包括涉及纯本地设置的有限情况，所有内容都应在源代码控制中。源代码控制的法则是，所有推送的内容都应由退出的人预期。不幸的是，日食经常导致类似这样的事情发生.classpath：

    <classpathentry kind="con" 
      path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.launching.macosx.MacOSXType/Java SE 7"/>

因此，在我的Mac上，这可行，也许Mac上的某人具有相同的JRE，但这不适用于其他任何人。

同样，没有简单的方法可以解决此问题。Eclipse将始终在其中添加该文件。我希望在其中添加.classpath文件，因为我们的lib文件夹中存在一些我们关心版本控制的第三方JAR，因此我们将其保留在那里，因此新开发人员不必获取它们。我们正在移至托管系统，但仍签入了托管+非托管依赖关系。这意味着所有开发人员只需确保两个目录都位于.classpaths中。但是，这比每次拉动都必须修复JRE并在每次提交时都要对.classpath进行更改要好。

Eclipse可以为您做一些其他的事情。.project文件通常在各个实例中是相同的，因此请包括在内。但是，有关Eclipse的源代码控制的最好的事情是“运行配置”设置。在“运行配置”对话框的“常用”选项卡下，保存配置，以便配置在同事的“调试和运行”收藏夹列表中显示。对我来说，目录中有一堆.launch文件.settings，因此我们都可以使用它们。

所以我说：.settings目录进入启动配置的源代码控制（* .prefs除外）

.classpath 呆在外面

.project 进去。

我将检入这些文件，以使新用户的入门尽可能容易。充其量，用户应该签出项目，并且应该能够在没有额外知识的情况下运行它。对于此文件，规则与项目中其他文件的规则相同：请谨慎处理。您不应在源代码中放置绝对路径，而应在配置文件中放置绝对路径。

如果以从头开始运行项目的方式检查文件，则应该没有太大的力量来更改它们。

我建议您将文件检入Subversion，前提是它们不包含绝对路径和其他将它们直接绑定到单个开发人员环境的数据。

如果文件确实包含绝对路径等，那么自述文件将是更好的选择。

是的，一定要签入它们，但是请确保您记录了所有路径依赖关系，并在可能的情况下避免使用绝对路径。

如果您不签入它们，那么签出项目的任何人都需要重新创建所有这些设置，这很烦人并且容易出错。

生成这些文件的脚本可能会更好地处理某些复杂的设置，但通常最好将它们检入。