.classpath 和 .project - 是否检查版本控制？
我正在运行一个开源 java 项目，该项目由依赖树中的多个模块组成。所有这些模块都是 subversion 存储库中的子目录。对于我们项目的新手来说，在 Eclipse 中手动设置所有这些工作量很大。
并非我们所有的开发人员都使用 eclipse。尽管如此，我们正在考虑仅签入 .classpath 和 .project 文件来帮助新手入门。这是个好主意吗？或者这会导致这些文件中不断发生冲突吗？有没有其他方法可以使项目在 Eclipse 上轻松设置？
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.
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
如果文件不包含绝对路径和其他将它们直接绑定到单个开发人员环境的数据，我建议您将文件签入 subversion。
如果文件确实包含绝对路径等，那么自述文件将是更好的选择。
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.
If the files do contain absolute paths and the like, a README would be a better choice.
是的，一定要签入它们，但请确保记录所有路径依赖关系，并尽可能避免绝对路径。
如果您不签入它们，那么任何签出项目的人都需要重新创建所有这些设置，这很烦人并且可能容易出错。
一些复杂的设置可能可以通过脚本更好地处理来生成这些文件，但通常最好只是将它们签入。
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.
绝对是的，正如我在“中所说的那样将您的项目文件置于版本控制之下？”
但是...这实际上仅适用于最近的 Eclipse3.5 设置，其中构建路径支持相对路径：
Eclipse3.6会更好，因为它在
链接资源中支持路径变量的相对路径：（自 3.6M5 起）
Definitively yes, as I said in "Do you keep your project files under version control?"
But... this is actually true only for recent Eclipse3.5 settings, where build paths support relative paths:
And Eclipse3.6 would be better, as it supports relative paths for path variables in
Linked Resources:(since 3.6M5)
绝对不行——通过颠覆来分发项目文件通常是个糟糕的主意。特别是因为有人可能会以某种奇怪的方式修改它们。项目文档中的一个好页面是一个更好的主意。我们的项目还有许多模块和复杂的设置。我们建立了一个 Confluence 页面，描述如何在每个流行的 IDE（IntelliJ、Eclipse、NetBeans）上开始使用该项目。 Subversion 中的自述文件包含相同的信息。
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.
我投反对票，但那是因为我通常会从 Maven 生成这些文件
I vote no, but that's because I would generally generate these files from maven
根据我的经验，除了涉及纯粹本地设置的有限情况外，一切都应该在源代码控制中。源代码控制法则是，所有推入的东西都应该被那些退出的人所期待。不幸的是，eclipse 经常会导致
.classpath中出现这样的情况：所以在我的 Mac 上这是可行的，也许 Mac 上的某个人有相同的 JRE，但这对其他人不起作用。
而且，没有简单的方法可以解决这个问题。 Eclipse 总是会添加它。我想在那里有 .classpath 文件，因为我们的 lib 文件夹中有一些第三方 JAR，我们关心版本控制，所以我们把它们留在那里，这样新开发人员就不必获取它们。我们正在转向托管系统，但仍然签入托管+非托管依赖项。这意味着所有开发人员只需确保两个目录位于其 .classpath 中。但这比每次拉取时都必须修复 JRE 并在每次提交时更改 .classpath 要好。
不过 Eclipse 还为您做了一些其他的好事。 .project 文件在各个实例中通常是相同的，因此请包含该文件。但 Eclipse 源代码管理的最佳功能是运行配置设置。在“运行配置”对话框的“常用”选项卡下，保存配置，以便您的同事在“调试”和“运行”的收藏夹列表下显示它们。对我来说，一堆
.launch文件位于.settings目录中，因此我们都可以使用它们。所以我说：
.settings目录进入启动配置的源代码管理（*.prefs 除外）.classpath留在外面.project进入。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:So on my Mac this works, and maybe someone on a Mac has the same JRE, but this will not work for anyone else.
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 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.So I say:
.settingsdirectory goes into source control for launch configs (except *.prefs).classpathstays out.projectgoes in.我会签入这些文件，以使新用户尽可能轻松地开始。最好的情况是用户应该检查该项目并且应该能够在没有额外知识的情况下运行它。对于此文件，规则与项目中的其他文件相同：小心处理它们。您不应在源代码中放置绝对路径，也不应在配置文件中放置绝对路径。
如果以项目从头开始运行的方式签入文件，则不应有太大的力量来更改它们。
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.