eclipse .classpath 和 .project - 是否检查版本控制？

.classpath and .project - check into version control or not?

提问by amarillion

I'm running an open source java project that consists of multiple modules in a tree of dependencies. All those modules are subdirectories in a subversion repository. For newcomers to our project, it's a lot of work to set all that up manually in eclipse.

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

Not all our developers use eclipse. Nevertheless, we're considering to just check in the .classpath and .project files to help newcomers to get started. Is this a good idea? Or would that lead to constant conflicts in those files? Is there an alternative way to make the project easy to set up on eclipse?

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

采纳答案by VonC

Definitively yes, as I said in "Do you keep your project files under version control?"

绝对是的，正如我在“您是否将项目文件置于版本控制之下？”

"Load it up, set it up, go."

“装好，装好，走。”

But... this is actually true only for recent Eclipse3.5 settings, where build paths support relative paths:

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

---

---

And Eclipse3.6 would be better, as it supports relative paths for path variablesin Linked Resources:

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

(since 3.6M5)

（从 3.6M5 开始）

回答by Bozhidar Batsov

Definitely no - it's generally terrible idea to distribute project files via subversion. Especially since someone might modify them in a some strange manner. A good page in the project's documentation is a much better idea. Our project also has many modules and a complex setup. We've set up a confluence page describing how to get started with the project on each populer IDE - IntelliJ, Eclipse, NetBeans. A README file in Subversion contains the same info.

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

回答by Goibniu

I vote no, but that's because I would generally generate these files from maven

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

回答by Zak Patterson

In my experience, excluding the limited cases where purely local settings are involved, everything should be in source control. The law of source control is that everything pushed in should be expected to work by those who pull out. Unfortunately, eclipse often causes things like this to be in .classpath:

根据我的经验，除了涉及纯本地设置的有限情况外，一切都应该在源代码控制中。源代码控制的法则是，推入的一切都应该被拉出的人所用。不幸的是，eclipse 经常会导致这样的事情.classpath：

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

So on my Mac this works, and maybe someone on a Mac has the same JRE, but this will not work for anyone else.

所以在我的 Mac 上这有效，也许 Mac 上的某个人有相同的 JRE，但这对其他人不起作用。

Also, there's no easy way around this. Eclipse will always add that in. I WANT to have the .classpath file in there, because there are some 3rd party JARs in our lib folder where we care about versioning, so we leave them in there so new developers do not have to get them. We're moving to a managed system, but still have managed+unmanaged dependencies checked in. This means all the developers just have to ensure two directories are in their .classpaths. But it's better than having to fix your JRE every single time you pull and have a change in your .classpath every single time you commit.

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

Eclipse does some other nice things for you though. The .project file will usually be the same across instances, so include that. But the best thing about source control for eclipse is the Run Configurations settings. Under the "Common" tab in the Run Configurations dialog, save the configurations so they appear for your colleagues under the favorites lists for Debug and Run. For me, a bunch of .launchfiles go in the .settingsdirectory, so we can all use them.

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

So I say: .settingsdirectory goes into source control for launch configs (except *.prefs)

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

.classpathstays out

.classpath留在外面

.projectgoes in.

.project进去。

回答by Arne Deutsch

I would check theese files in to make the start for new users as easy as possible. At best the user should check out the project and should be able to run it without extra knowledge. For this files the rules are the same as for other files in the project: handle them with care. You should not place absolute pathes in the source code, neigther you should in the configuration files.

我会检查这些文件，以使新用户尽可能轻松地开始。充其量用户应该检查项目并且应该能够在没有额外知识的情况下运行它。对于此文件，规则与项目中的其他文件相同：小心处理。您不应在源代码中放置绝对路径，也不应在配置文件中放置。

If the files are checked in in a way that the project runs from scratch there should not be much forces to change them.

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

回答by vkraemer

I would recommend that you check the files into subversion IF they do not contain absolute paths and other data which would tie them directly to a single developer's environment.

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

If the files do contain absolute paths and the like, a README would be a better choice.

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

回答by Christopher Barber

Yes, definitely check them in, but make sure that you document any path dependencies and avoid absolute paths if possible.

是的，一定要检查它们，但请确保记录所有路径依赖项，并尽可能避免使用绝对路径。

If you don't check them in, then anyone checking the project out will need to recreate all of those settings, which is annoying and potentially error prone.

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

Some complex setups may be better handled by a script to generate these files, but usually it is better to just check them in.

一些复杂的设置可能更好地由脚本处理以生成这些文件，但通常最好只将它们签入。