我们有一个相当复杂的多模块 Maven 项目。有 Flex 模块、GWT 模块、Java 模块和许多 WAR 模块。为了简化将这些项目导入 Eclipse 的过程，过去我们已将所有相关的 Eclipse 项目文件包含在源代码树中。
然而，这在过去一直是问题的根源，因为有时这些文件会被意外修改并签入……从而给其他开发人员带来问题。随着 M2E 的出现及其对配置器的新支持，以帮助在导入时设置 Eclipse 项目，我们正在重新考虑这一策略。
一般来说，项目是否在 Subversion/Git/etc 中包含这些 Eclipse 文件？
We have a rather complicated multi-module Maven project. There are Flex modules, GWT modules, Java modules, and a number of WAR modules. In order to simply the process of importing these projects into Eclipse, historically we have included all the relevant Eclipse project files in the source tree.
However, this has been a source of problems in the past because sometimes those files are modified accidently and checked in...thus causing problems for other developers. With the advent of M2E and its new support for configurators to help set up Eclipse projects upon import, we are rethinking this strategy.
In general, do projects include these Eclipse files in Subversion/Git/etc?
发布评论
评论（4）
顶级答案：这完全是一个品味问题 :-)
就我个人而言，对于“内部”项目（您对其他开发人员的环境有一定的控制权），我确实包含 Eclipse 文件，但需要注意您必须确保每个人都在其配置中使用相对路径。 （每隔几个月，我们就会遇到一次构建中断，因为库路径是硬编码的。需要几秒钟才能修复，但很烦人。）我通常还大量使用 Eclipse 代码格式化和编译器警告等功能设置使生活更轻松（例如，没有大量的 Subversion 签入，因为某人的编辑者在格式化选项卡上发生了争执）。
作为奖励，当您聘请新开发人员时，Eclipse Subversion 签出系统将在检测到主干/分支中的 .project 文件时自动配置项目。如果您使用 Eclipse 来管理您的构建（而不是 Ant 或 Make），那么这就是双赢。
如果您在一个更加多元化的团队中（例如：使用 Eclipse 的方式不同（原文如此？）），那么在实践中，它们并不是“太大”的麻烦。我正在处理一个“协作”项目，该项目有一个充满 MicroSoft Visual Studio 控制文件和 .project 文件的文件夹，并且它们必须临时保持同步，但至少有“只有两个”集要同步的文件的数量。如果 Subversion 中没有它们，每个开发人员就会有一个……
我也听说过使用“虚拟项目”来保存项目文件。例如，
我见过的唯一一个地方是一个具有大型 GPL 分支和一个小型非 GPL 本地专有插件存储库的项目……GPL 分支没有 .project 文件，因为大多数“Net”合作者没有使用 Eclipse，项目文件位于内部（专用）Subversion 服务器上，第三个项目包含专有插件代码。 （第四个用于艺术，第五个用于音乐......）
Top level answer: That's totally a matter of taste :-)
Personally, for "internal" projects (you have some control over the other developers' environments), I do include the Eclipse files, with the caveat that you have to be sure everyone uses relative paths in their configurations. (Every few months we'd have a build break because a library path was hard-coded. It took seconds to fix, but was annoying.) I also have typically made a lot of use of things like Eclipse code-formatting and compiler warnings settings to make life easier (e.g. no huge Subversion check-ins because someone's editors got into a fight over formatting tabs).
As a bonus, when you bring on a new developer, the Eclipse Subversion check-out system will auto-configure the project when it detects the .project files in your trunk/branch. This is a double Win if you use Eclipse to manage your build (as opposed to, say, Ant or Make).
If you're on a more diverse team (e.g.: not homogenously(sic?) using Eclipse), they aren't "much" of a nuisance, in practice. I have one "collaborative" project that I work on that has a folder full of MicroSoft Visual Studio control files and a .project file, and they have to be kept in sync ad-hoc, but at least there are "only two" sets of those files to sync up. Without them in Subversion, there would be one-per-developer…
I've heard of using a "dummy project" to hold project files, as well. e.g.
The only place I've seen that was in a project with a large GPL branch and a small repository of non-GPL local, proprietary plug-ins … the GPL branch didn't have .project files, as most of the 'Net collaborators were not using Eclipse, the project files were on the internal (private) Subversion server, and a third project contained the proprietary plug-in code. (And a fourth for art, a fifth for music…)
我个人不建议将项目配置文件包含在 SCM 中。 .project 文件包含相对或绝对路径或 URI，这些路径可能因用户而异。可以找到 .project 文件的规范 此处。
I personally don't recommend including your project config files in your SCM. The .project file contains the relative or absolute path, or URI, which can very from user to user. Specifications for the .project file can be found here.
我遇到的几乎所有（工作）项目都将 .project 文件存储在 SCM 中。主要是因为构建器等存储在文件中。因此所有开发人员在 Eclipse 中都有一致的配置。
想象一下这样的场景：除了一位开发人员之外，你们都在使用 Checkstyle，而该开发人员坚持在他的文件中添加选项卡:-)。
它不仅适用于 .project，还适用于 .classpath、.checkstyle、.settings 中的所有内容。
您唯一需要注意的是，您在项目中引用的所有内容都有一个相对于项目的路径，例如您的 checkstyle 配置。这意味着您使用的所有内容也可能都在 SCM 中。但这是一个优势，因为这都是您流程的一部分，对吧？
由于使用的 IDE 多种多样，上述内容不一定适用于 FOSS 项目。
Pretty much all of the (work) projects I've come across store the .project files in an SCM. Mainly for the reason that builders etc are stored in the file. So all of the developers have a consistent configuration in Eclipse.
Imagine the scenario that you're all using Checkstyle apart from one developer, who insists on putting tabs in his files :-).
It doesn't just apply to .project, but .classpath, .checkstyle, everything in .settings.
The only thing you have to be careful of is that everything that you refer to in your projects has a path relative to the project, for instance your checkstyle configuration. This means that everything you use will probably be in the SCM as well. But this is an advantage, because this is all part of your process right?
The above doesn't necessarily apply to FOSS projects, because of the diversity of IDEs used.
您可以考虑将 maven-eclipse 插件添加到您的 pom.xml 中。因此，开发人员可以查看源代码，并在本地构建他们的 Eclipse 项目，然后导入到工作区。
另外，如果您有常见的 eclipse（或 eclipse 插件）相关配置文件，您也可以在 maven-eclipse-plugin 中定义它们。例如 checkstyle.xml、codeTemplate.xml、codeFormatter.xml...将这些文件保存在 scm 中可能是一个好主意。
you may consider to add maven-eclipse plugin into your pom. thus, developer could check out the source codes, and locally build their eclipse project, and import to workspace.
also if you have common eclipse (or eclipse plugin) related config files, you could define them in maven-eclipse-plugin too. e.g. checkstyle.xml, codeTemplate.xml, codeFormatter.xml.... save those those files in scm could be a good idea.