.classpath和.project - 检查版本控制与否?

时间:2010-05-12 11:17:38

标签: eclipse version-control ide

我正在运行一个开源java项目,该项目由依赖项树中的多个模块组成。所有这些模块都是subversion存储库中的子目录。对于我们项目的新手来说,在eclipse中手动设置所有这些工作需要做很多工作。

并非所有开发人员都使用eclipse。不过,我们正在考虑检查.classpath和.project文件,以帮助新手入门。这是一个好主意吗?或者这会导致这些文件中的持续冲突?有没有其他方法可以让项目在eclipse上轻松设置?

7 个答案:

答案 0 :(得分:63)

肯定是的,正如我在“Do you keep your project files under version control?”中所说的

  

“加载,设置,继续。”

但是......这实际上只适用于最近的Eclipse3.5设置,其中构建路径支持相对路径

Build path supports relative paths


Eclipse3.6会更好,因为支持Linked Resources中路径变量的相对路径

path variable with relative path
(自3.6M5起)

答案 1 :(得分:17)

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

答案 2 :(得分:9)

我投反对票,但那是因为我通常会从maven

生成这些文件

答案 3 :(得分:5)

我会检查这些文件,以便尽可能简化新用户的入门。用户应该检查项目,并且应该能够在没有额外知识的情况下运行它。对于此文件,规则与项目中的其他文件相同:小心处理它们。您不应该在源代码中放置绝对路径,您应该在配置文件中。

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

答案 4 :(得分:5)

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

如果文件包含绝对路径等,则自述文件将是更好的选择。

答案 5 :(得分:5)

根据我的经验,排除涉及纯粹本地设置的有限情况,一切都应该在源代码控制中。源头控制的法则是,所有被推进的东西应该被那些退出的人工作。不幸的是,eclipse经常导致这样的事情发生在.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,我们关心版本控制,所以我们把它们放在那里,所以新的开发人员不必得到它们。我们正在迁移到托管系统,但仍然检查了托管+非托管依赖项。这意味着所有开发人员只需要确保两个目录都在.classpath中。但是,每次提取时都必须修复JRE并在每次提交时更改.classpath。

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

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

.classpath不在乎

.project进去了。

答案 6 :(得分:2)

是的,肯定会检查它们,但请确保记录任何路径依赖关系并尽可能避免使用绝对路径。

如果你没有检查它们,那么任何检查项目的人都需要重新创建所有这些设置,这很烦人并且可能容易出错。

脚本可以更好地处理一些复杂的设置来生成这些文件,但通常最好只检查它们。