Eclipse 工作区：用于什么以及为什么？

Eclipse Workspaces: What for and why?

提问by e-motiv

I have seen, read and thought of different ways of using workspaces (per project, per application (multi-asseted or not), per program language, per target (web-development, plugins,..), and so on) and I am still doubting what the best approach is.

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

Can anyway give an elaborate, but not a page long insight into this?

无论如何都可以详细说明这一点，但不是一页长的洞察力吗？

This involves a lot of sub-questions, so to speak, and I don't know all the specific sub-questions I should ask, because I am not sure I don't know all the aspects of eclipse (and workspaces), but I'll try to give an example of what I am looking for:

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

• What for?
  
  • What did eclipse development mean it to be used for?
  • What do other/most people think?
  • What do you think?
  • ... ?
• Why?
  
  • Are there configuration conflicts vs. sharing merits?
  • Any filespace reasons?
  • Performance?
  • ... ?

• 做什么的？
  
  • eclipse 开发意味着它的用途是什么？
  • 其他/大多数人怎么看？
  • 你怎么认为？
  • ……？
• 为什么？
  
  • 是否存在配置冲突与共享优点？
  • 任何文件空间原因？
  • 表现？
  • ……？

Oh, and I am speaking of the minimum use case for a developer that uses different languages and protocols, and NOT necessarily all of them in one project (E.g. php, javascript and xml for some projects, C# for others, java and SQL for still others, etc..)

哦，我说的是使用不同语言和协议的开发人员的最低用例，不一定所有这些都在一个项目中（例如，某些项目使用 php、javascript 和 xml，其他项目使用 C#，仍然使用 Java 和 SQL其他等等。）

Edit 2012-11-27: Don't get me wrong. I don't doubt the use of workspaces, I just want to use it as it is meant to be or otherwise if anyone would think it better. So "what for?" means: What's the best use? And "why?" actually targets on the "what for?", in other words: tell me the reasons for your answer.

编辑 2012-11-27：不要误会我的意思。我不怀疑工作区的使用，我只是想按照它本来的样子使用它，或者如果有人认为它更好的话。所以“为了什么？” 意思是：什么是最好的用途？以及“为什么？” 实际上针对“为什么？”，换句话说：告诉我你回答的原因。

回答by Rafael Eyng

I'll provide you with my vision of somebody who feels very uncomfortable in the Java world, which I assume is also your case.

我将向您提供我对在 Java 世界中感到非常不舒服的人的看法，我认为这也是您的情况。

What it is

这是什么

A workspace is a concept of grouping together:

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

1. a set of (somehow) related projects
2. some configuration pertaining to all these projects
3. some settings for Eclipse itself

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

This happens by creating a directory and putting inside it (you don't have to do it, it's done for you) files that manage to tell Eclipse these information. All you have to do explicitly is to select the folder where these files will be placed. And this folder doesn't need to be the same where you put your source code - preferentially it won't be.

这是通过创建一个目录并将其放入（您不必这样做，它已经为您完成）文件来实现的，这些文件设法将这些信息告诉 Eclipse。您所要做的就是选择放置这些文件的文件夹。并且此文件夹不需要与您放置源代码的位置相同 - 最好不会。

Exploring each item above:

探索上面的每个项目：

1. a set of (somehow) related projects

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

Eclipse seems to always be opened in association with a particular workspace, i.e., if you are in a workspace Aand decide to switch to workspace B(File > Switch Workspaces), Eclipse will close itself and reopen. All projects that were associated with workspace A(and were appearing in the Project Explorer) won't appear anymore and projects associated with workspace Bwill now appear. So it seems that a project, to be open in Eclipse, MUSTbe associated to a workspace.

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

Notice that this doesn't mean that the project source code must be inside the workspace. The workspace will, somehow, have a relation to the physical path of your projects in your disk (anybody knows how? I've looked inside the workspace searching for some file pointing to the projects paths, without success).

请注意，这并不意味着项目源代码必须在工作区中。以某种方式，工作区将与磁盘中项目的物理路径相关（有人知道怎么做？我在工作区内部搜索了一些指向项目路径的文件，但没有成功）。

This way, a project can be inside more than 1 workspace at a time. So it seems good to keep your workspace and your source code separated.

这样，一个项目一次可以位于 1 个以上的工作区中。因此，将工作区和源代码分开似乎很好。

2. some configuration pertaining to all these projects

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

I heard that something, like the Java compiler version (like 1.7, e.g - I don't know if 'version' is the word here), is a workspace-level configuration. If you have several projects inside your workspace, and compile them inside of Eclipse, all of them will be compiled with the same Java compiler.

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

3. some settings for Eclipse itself

3. Eclipse 本身的一些设置

Some things like your key bindings are stored at a workspace-level, also. So, if you define that ctrl+tab will switch tabs in a smart way (not stacking them), this will only be bound to your current workspace. If you want to use the same key binding in another workspace (and I think you want!), it seems that you have to export/import them between workspaces (if that's true, this IDE was built over some really strange premises). Here is a link on this.

一些诸如键绑定之类的内容也存储在工作区级别。因此，如果您定义 ctrl+tab 将以智能方式切换选项卡（而不是堆叠它们），则这将仅绑定到您当前的工作区。如果你想在另一个工作区中使用相同的键绑定（我认为你想要！），似乎你必须在工作区之间导出/导入它们（如果是这样，这个 IDE 是在一些非常奇怪的前提上构建的）。这是关于此的链接。

It also seems that workspaces are not necessarily compatible between different Eclipse versions. This articlesuggests that you name your workspaces containing the name of the Eclipse version.

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

And, more important, once you pick a folder to be your workspace, don't touch any file inside there or you are in for some trouble.

而且，更重要的是，一旦你选择了一个文件夹作为你的工作区，不要触摸里面的任何文件，否则你会遇到一些麻烦。

How I think is a good way to use it

我认为是一个很好的使用方式

(actually, as I'm writing this, I don't know how to use this in a good way, that's why I was looking for an answer – that I'm trying to assemble here)

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

1. Create a folder for your projects:
   /projects

2. Create a folder for each project and group the projects' sub-projects inside of it:
   /projects/proj1/subproj1_1
/projects/proj1/subproj1_2
/projects/proj2/subproj2_1

3. Create a separate folder for your workspaces:
   /eclipse-workspaces

4. Create workspaces for your projects:
   /eclipse-workspaces/proj1
/eclipse-workspaces/proj2

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

回答by Duncan Krebs

The whole point of a workspace is to group a set of related projects together that usually make up an application. The workspace framework comes down to the eclipse.core.resourcesplugin and it naturally by design makes sense.

工作区的全部意义在于将一组通常构成应用程序的相关项目组合在一起。工作区框架归结为eclipse.core.resources插件，它的设计自然是有意义的。

Projects have natures, builders are attached to specific projects and as you change resources in one project you can see in real time compile or other issues in projects that are in the same workspace. So the strategy I suggest is have different workspaces for different projects you work on but without a workspace in eclipse there would be no concept of a collection of projects and configurations and after all it's an IDE tool.

项目具有性质，构建器附加到特定项目，当您更改一个项目中的资源时，您可以实时查看同一工作区中项目的编译或其他问题。所以我建议的策略是为您处理的不同项目使用不同的工作区，但如果没有 Eclipse 中的工作区，就不会有项目和配置集合的概念，毕竟它是一个 IDE 工具。

If that does not make sense ask how Net Beans or Visual Studio addresses this? It's the same theme. Maven is a good example, checking out a group of related maven projects into a workspace lets you develop and see errors in real time. If not a workspace what else would you suggest? An RCP application can be a different beast depending on what its used for but in the true IDE sense I don't know what would be a better solution than a workspace or context of projects. Just my thoughts. - Duncan

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

回答by Lazaros Kosmidis

Basically the scope of workspace(s) is divided in two points.

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

First point (and primary) is the eclipse it self and is related with the settings and metadata configurations (plugin ctr). Each time you create a project, eclipse collects all the configurations and stores them on that workspace and if somehow in the same workspace a conflicting project is present you might loose some functionality or even stability of eclipse it self.

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

And second (secondary) the point of development strategy one can adopt. Once the primary scope is met (and mastered) and there's need for further adjustments regarding project relations (as libraries, perspectives ctr) then initiate separate workspace(s) could be appropriate based on development habits or possible language/frameworks "behaviors". DLTK for examples is a beast that should be contained in a separate cage. Lots of complains at forums for it stopped working (properly or not at all) and suggested solution was to clean the settings of the equivalent plugin from the current workspace.

第二（次要）发展战略的要点。一旦满足（并掌握）主要范围并且需要进一步调整项目关系（如库、透视 ctr），然后根据开发习惯或可能的语言/框架“行为”启动单独的工作区可能是合适的。例如，DLTK 是一只野兽，应该被关在一个单独的笼子里。在论坛上有很多抱怨它停止工作（正确或根本不工作），建议的解决方案是清除当前工作区中等效插件的设置。

Personally, I found myself lean more to language distinction when it comes to separate workspaces which is relevant to known issues that comes with the current state of the plugins are used. Preferably I keep them in the minimum numbers as this is leads to less frustration when the projects are become... plenty and version control is not the only version you keep your projects. Finally, loading speed and performance is an issue that might come up if lots of (unnecessary) plugins are loaded due to presents of irrelevant projects. Bottom line; there is no one solution to every one, no master blue print that solves the issue. It's something that grows with experience, Less is more though!

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

回答by pbyhistorian

Although I've used Eclipse for years, this "answer" is only conjecture (which I'm going to try tonight). If it gets down-voted out of existence, then obviously I'm wrong.

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

Oracle relies on CMake to generate a Visual Studio "Solution" for their MySQL Connector C source code. Within the Solution are "Projects" that can be compiled individually or collectively (by the Solution). Each Project has its own makefile, compiling its portion of the Solution with settings that are different than the other Projects.

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

Similarly, I'm hoping an Eclipse Workspace can hold my related makefile Projects (Eclipse), with a master Project whose dependencies compile the various unique-makefile Projects as pre-requesites to building its "Solution". (My folder structure would be as @Rafael describes).

同样，我希望 Eclipse 工作区可以保存我的相关 makefile 项目 (Eclipse)，主项目的依赖项将各种独特的 makefile 项目编译为构建其“解决方案”的先决条件。（我的文件夹结构就像@Rafael 描述的那样）。

So I'm hoping a good way to use Workspaces is to emulate Visual Studio's ability to combine dissimilarProjects into a Solution.

所以我希望使用工作区的一个好方法是模拟 Visual Studio 将不同的项目组合成一个解决方案的能力。