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

ama*_*ion 85 eclipse ide version-control

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

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

Von*_*onC 63

肯定是的,正如我在" 您是否将项目文件保留在版本控制下? "中所述.

"加载它,设置它,然后去."

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

构建路径支持相对路径


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

具有相对路径的路径变量
(自3.6M5起)

  • 哇,我不知道他们加了这个...会不会让我们感到悲伤 (2认同)

Boz*_*sov 17

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

  • 我不能同意.根据我的经验,最好检查一下这些文件,以便尽可能简单地结账.有人可能会以某种奇怪的方式改变它们吗?有人可能会以某种奇怪的方式更改您的代码...... (29认同)
  • -1,不能不同意.项目设置是项目日常工作的重要*部分.意外检查错误设置的缺点远小于自动保持每个人都是最新的优点.毕竟,您可以轻松地返回到以前的版本. (7认同)
  • 每个人都有权发表意见.事实上,我从来没有创建过依赖Eclipse(或任何其他IDE)项目系统的项目...... Maven是最终的项目理解工具,并且使IDE特定的设置过时.有时间注意到当前设置出现问题并返回上一版本与自行调整任何新设置的时间不太可能不同.至少在我公司,如果在更大的更改后需要一些用户干预,团队中的每个人都会收到电子邮件通知. (6认同)
  • 任何IDE的项目文件实际上都不是任何项目的一部分 - 如果你想分发它们 - 请将它们附加到我提到的文章中.通常,团队中的每个人都可以修改repo中的文件,但不是每个人都可以将新文件附加到重要的文档节点等.很容易让人忘记忽略类路径和项目文件并在不应该的时候提交它们.即使你让他们处于颠覆状态 - 你当然应该将他们放在一边...... (5认同)

Goi*_*niu 9

我投反对票,但那是因为我通常会从maven生成这些文件


Arn*_*sch 5

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

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


vkr*_*mer 5

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

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


Zak*_*son 5

根据我的经验,排除涉及纯粹本地设置的有限情况,一切都应该在源代码控制中.源控制的法则是,所有被推进的东西应该被那些退出的人工作.不幸的是,eclipse常常导致这样的事情发生在.classpath:

    <classpathentry kind="con" 
      path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.launching.macosx.MacOSXType/Java SE 7"/>
Run Code Online (Sandbox Code Playgroud)

因此,在我的Mac上,这可行,也许Mac上的某个人拥有相同的JRE,但这对任何其他人都无效.

此外,没有简单的方法来解决这个问题.Eclipse总是会添加它.我想在那里有.classpath文件,因为我们的lib文件夹中有一些第三方JAR,我们关心版本控制,所以我们把它们放在那里,所以新的开发人员不必得到它们.我们正在迁移到托管系统,但仍然检查了托管+非托管依赖项.这意味着所有开发人员只需确保其中有两个目录.classpath.但是,每次提交时都必须修复JRE并在每次提交时更改.classpath.

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

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

.classpath 呆在外面

.project 进来.