我已经看到，阅读并想到了使用工作空间的不同方式（每个项目，每个应用程序（是否有多个评估），每种程序语言，每个目标（Web开发，插件等等）等等），我仍然怀疑最好的方法是什么。

无论如何，能否对此进行详尽而不是一页的深入了解？

可以这么说，这涉及很多子问题，我不知道我应该问的所有具体子问题，因为我不确定我不知道Eclipse（和工作区）的所有方面，但是我将尝试举例说明我要寻找的东西：

• 做什么的？
  
  • 蚀发展意味着它被用来做什么？
  • 其他/大多数人怎么看？
  • 你怎么看？
  • ...？
• 为什么？
  
  • 是否存在配置冲突与共享优势？
  • 任何文件空间原因？
  • 性能？
  • ...？

哦，我是说使用不同语言和协议的开发人员的最小用例，而不必在一个项目中全部使用（例如，对于某些项目，例如php，javascript和xml；对于其他项目，则为C＃；对于静态项目，则为Java和SQL）其他，等等。）

编辑2012-11-27：不要误会我的意思。我毫不怀疑使用工作区，我只是想按原样使用它，如果有人认为它更好，那就应该使用它。那么“做什么用的？” 意思是：最好的用途是什么？还有“为什么？” 实际上针对“做什么？”，换句话说：告诉我您回答的原因。

我将为您提供一个在Java世界中感到非常不舒服的人的愿景，我认为这也是您的情况。

这是什么

工作空间是组合在一起的概念：

1. 一组（以某种方式）相关的项目
2. 与所有这些项目有关的一些配置
3. Eclipse本身的一些设置

这是通过创建目录并将其放入（告诉您不必执行，它已经为您完成）文件而完成的，这些文件可以告诉Eclipse这些信息。您只需要做的就是选择将要放置这些文件的文件夹。而且此文件夹不必与您放置源代码的位置相同-优先地，它不会相同。

浏览以上每个项目：

1. 一组（以某种方式）相关的项目

Eclipse似乎总是与特定的工作空间相关联地打开，即，如果您在工作空间A中并决定切换到工作空间B（“文件”>“切换工作空间”），Eclipse将关闭自身并重新打开。与工作空间A相关联的所有项目（并出现在项目资源管理器中）将不再显示，并且现在将显示与工作空间B相关联的项目。因此，似乎要在Eclipse中打开的项目必须与工作空间相关联。

注意，这并不意味着项目源代码必须在工作空间内。工作空间将以某种方式与磁盘中项目的物理路径有关系（有人知道吗？我一直在工作空间中寻找一些指向项目路径的文件，但没有成功）。

这样，一个项目一次可以位于一个以上的工作空间中。因此，将工作空间和源代码分开似乎是一件好事。

2. 与所有这些项目有关的一些配置

我听说某些东西是工作区级别的配置，例如Java编译器版本（例如1.7，例如-我不知道“版本”是不是这个词）。如果您的工作空间中有多个项目，并在Eclipse中进行编译，则所有项目都将使用相同的Java编译器进行编译。

3. Eclipse本身的一些设置

诸如键绑定之类的东西也存储在工作空间级别。因此，如果您定义ctrl + tab将以一种聪明的方式切换选项卡（而不是堆叠它们），则该选项卡将仅绑定到您当前的工作空间。如果您想在另一个工作空间中使用相同的键绑定（我想您想要！），似乎您必须在工作空间之间导出/导入它们（如果的确如此，则此IDE是在一些非常奇怪的前提下构建的）。这是一个链接。

似乎工作空间不一定在不同的Eclipse版本之间兼容。本文建议您为包含Eclipse版本名称的工作区命名。

而且，更重要的是，一旦您选择一个文件夹作为您的工作区，请不要触摸其中的任何文件，否则您会遇到麻烦。

我认为是使用它的好方法

（实际上，在撰写本文时，我不知道如何以一种很好的方式使用它，这就是为什么我一直在寻找答案–我试图在这里组装）

1. 为您的项目创建一个文件夹：
   /projects

2. 为每个项目创建一个文件夹，并将项目的子项目分组在其中：
   /projects/proj1/subproj1_1
/projects/proj1/subproj1_2
/projects/proj2/subproj2_1

3. 为您的工作区创建一个单独的文件夹：
   /eclipse-workspaces

4. 为您的项目创建工作区：
   /eclipse-workspaces/proj1
/eclipse-workspaces/proj2

工作区的重点是将通常构成应用程序的一组相关项目组合在一起。工作区框架归结为eclipse.core.resources插件，并且自然而然地通过设计是有意义的。

项目具有性质，构建器附加到特定项目，并且当您更改一个项目中的资源时，您可以实时查看同一工作空间中项目中的编译或其他问题。因此，我建议的策略是为要处理的不同项目提供不同的工作空间，但没有Eclipse的工作空间，就不会有项目和配置集合的概念，毕竟这是一个IDE工具。

如果那没有意义，请问Net Beans或Visual Studio如何解决这个问题？这是相同的主题。Maven是一个很好的例子，将一组相关的Maven项目检入到工作区中可以使您实时开发和查看错误。如果不是工作空间，您还会建议什么？根据用途，RCP应用程序可以是不同的野兽，但就真正的IDE而言，我不知道有什么比工作空间或项目上下文更好的解决方案。只是我的想法。-邓肯

基本上，工作空间的范围分为两点。

第一点（也是主要的）是它本身的蚀，并且与设置和元数据配置（插件ctr）有关。每次创建项目时，eclipse都会收集所有配置并将其存储在该工作区中，如果在同一个工作区中以某种方式存在冲突的项目，则可能会失去某些功能，甚至使其自身失去稳定性。

第二（第二）点可以采用的发展策略。一旦满足（并掌握了）主要范围，并且需要对项目关系进行进一步调整（如库，透视图ctr），则根据开发习惯或可能的语言/框架“行为”，启动单独的工作空间可能是适当的。例如，DLTK是一种野兽，应放在单独的笼子中。在论坛上很多抱怨它停止工作（正确或根本不起作用），建议的解决方案是从当前工作空间中清除等效插件的设置。

就个人而言，当涉及单独的工作区时，我发现自己更倾向于语言区分，这与使用插件当前状态所带来的已知问题有关。最好我将它们的数量保持在最低限度，因为这会在项目变成项目时减少挫败感……大量的版本控制不是您保留项目的唯一版本。最后，如果由于不相关项目的存在而加载了许多（不必要的）插件，则加载速度和性能可能是一个问题。底线；没有一种解决方案可以解决所有问题，也没有解决方案的主要蓝图。这是随着经验而增长的，尽管少即是多！

尽管我已经使用Eclipse多年了，但是这个“答案”只是一个推测（今晚我将尝试尝试）。如果它被淘汰，那显然我是错的。

Oracle依靠CMake为他们的MySQL Connector C源代码生成Visual Studio“解决方案”。解决方案中包含“项目”，这些项目可以单独或共同（通过解决方案）进行编译。每个项目都有其自己的makefile，使用与其他项目不同的设置来编译其在解决方案中的部分。

同样，我希望Eclipse Workspace可以容纳一个相关的Makefile项目（Eclipse），并拥有一个主项目，该项目的依赖项可以编译各种唯一的Makefile项目，作为构建其“解决方案”的先决条件。（我的文件夹结构将如@Rafael所述）。

因此，我希望使用Workspaces的一种好方法是模仿Visual Studio将异类项目组合成解决方案的能力。