有人告诉我，Eclipse 工作区相当于 Visual Studio 解决方案。但我也被告知人们通常使用一个工作区来完成所有工作。这些明显相互矛盾的陈述是否正确？如果是，那么我们如何在 Eclipse 中创建和维护等效的多个 VS 解决方案？
其次，对于 VS，我也将我的解决方案 (.sln) 文件检入到源代码管理中。相应地，我应该还是不应该检查 Eclipse 工作区的 .metadata 文件夹？
【问题讨论】：
标签： eclipse conventions organization
我不认为，Eclipse 工作区等同于 VS 解决方案。 Eclipse 工作区存储了很多关于项目的元信息、它们的物理位置（可能在工作区文件夹中或之外）等，甚至是工作台设置。将此信息上传到源代码管理中不是一个好主意，因为其他开发人员可能会为项目使用其他物理位置等。
Eclipse 中有一个与解决方案类似的概念（类似，不等价）：项目集。将项目分组到集合中只是一个 GUI 选项。这些集合不能一起执行，并且仅在项目导航器中可见。
另一种方法是创建多个工作区文件夹，您可以将它们用作解决方案的替代方案。这种方法的缺点是，如果您自定义 IDE（例如，通过使用首选项，或通过定义源代码控制位置），则必须在每个工作区中进行这些自定义。这个问题可以使用Workspace Mechanic工具解决（我没试过，但是可以迁移这些设置）。
【讨论】：
对我来说，为单个项目拥有一个单独的工作区更好的主要原因是性能和清晰度。由于一个工作区中有许多项目，您必须关闭其他项目，因为共享类路径以获得编辑器帮助。编辑器使用所有项目的类路径进行内容辅助、类层次结构查找等。
Eclipse 预计打开的项目是相关的。而在使用像Maven这样的项目管理器时，一个maven项目通常会分成很多个小的eclipse项目。为项目提供单独的工作区只是最佳实践。第二个原因是，通常您需要导入另一个相关项目以查看事情是如何完成的，然后将它们全部放在一个工作区中会很糟糕。
您绝对不应该将 .metadata 文件夹提交到源代码管理中。你只提交里面的项目。因为您和其他人只会将项目签出到他们自己的工作区中。但是你是否应该提交 .project 文件是一个问题，因为它是个性化的和特定于 Eclipse 版本的，并且项目性质（java、spring、maven 性质等）之类的东西可以由任何人自己设置。项目中的 .classpath 文件应该提交到源代码管理，因为它们指定了类路径，重新设置会非常耗时。
【讨论】：
您可以将项目分组到不同的工作区或特定的工作区。正确管理设置后不会有害。
【讨论】：