.classpath和.project – 检查版本控制或不？
我正在运行一个开源的java项目，它由依赖关系树中的多个模块组成。 所有这些模块都是Subversion版本库中的子目录。 对于我们项目的新手来说，在eclipse中手动设置所有这些工作是很多的。
不是所有的开发者都使用eclipse。 不过，我们正在考虑只检查.classpath和.project文件，以帮助新手入门。 这是一个好主意吗？ 或者这会导致这些文件中的冲突不断？ 有没有其他的方法来使项目易于在Eclipse上设置？
肯定是的，正如我在“ 你把你的项目文件控制在版本控制之下吗？
“把它装起来，放好，去吧。”
但是…这实际上只适用于最近的Eclipse3.5设置，其中构buildpath支持相对path ：
而Eclipse3.6会更好，因为它支持 Linked Resources pathvariables的相对path ：
（自3.6M5起）
绝对没有 – 通过颠覆分发项目文件通常是一个糟糕的主意。 特别是因为有人可能会以一种奇怪的方式修改它们。 项目文档中的一个好页面是一个更好的主意。 我们的项目也有很多模块和一个复杂的设置。 我们已经build立了一个汇总页面，介绍如何开始使用每个populer IDE上的项目 – IntelliJ，Eclipse，NetBeans。 Subversion中的README文件包含相同的信息。
我没有投票，但这是因为我通常会从maven生成这些文件
我会检查这些文件，以尽可能简化新用户的开始。 用户至多应该检查项目，并应该能够运行它没有额外的知识。 对于这个文件，规则与项目中的其他文件相同：小心处理它们。 你不应该放置在源代码中的绝对path，不应该在configuration文件中。
如果以从头开始运行项目的方式检入文件，则不应该有太多的力量来改变它们。
我build议你检查文件到Subversion如果他们不包含绝对path和其他数据，将他们直接绑定到一个开发人员的环境。
如果这些文件包含绝对path等，则自述文件将是更好的select。
根据我的经验，除了涉及纯粹的本地设置的有限情况外，一切都应该在源代码控制之中。 源头控制的规律是，所有推进的东西都应该由那些退出的人来工作。 不幸的是，日食通常会导致这样的事情在.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，所以我们把它们留在那里，所以新的开发人员不必去获取它们。 我们正在转向托pipe系统，但仍然托pipe了托pipe+非托pipe依赖关系。这意味着所有开发人员只需确保两个目录位于其.classpath 。 但是每次执行的时候都要修正你的JRE，每次执行的时候都要改变你的.classpath。
Eclipse虽然为你做了一些其他好的事情。 .project文件通常在不同的实例中是相同的，所以包括这个。 但关于eclipse的源代码控制的最好的事情是运行configuration设置。 在“运行configuration”对话框中的“公共”选项卡下，保存configuration，使其显示在“debugging和运行”collections夹列表下的同事处。 对我来说，一堆.launch文件进入.settings目录，所以我们都可以使用它们。
所以我说： .settings目录进入源代码控制启动configuration（除* .prefs）
.classpath保持不变
。项目进入。
是的，一定要检查它们，但要确保你logging了任何path依赖关系，并尽可能避免绝对path。
如果你不检查他们，那么任何人检查项目将需要重新创build所有这些设置，这是烦人的，并可能容易出错。
生成这些文件的脚本可能会更好地处理一些复杂的设置，但通常最好只检查它们。
