160

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.

Can anyone give a detailed, 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, as I am sure I don't know all aspects of Eclipse (and Workspaces), but I'll try to give an example of what I am looking for:

  • What for?
  • What did the Eclipse development team expect 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?
  • ... ?

I am speaking of the minimum use-case for a developer that uses different languages and protocols, 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..)

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.

Stu
  • 30,392
  • 6
  • 14
  • 33
e-motiv
  • 5,795
  • 5
  • 27
  • 28
  • 14
    I still don't get it. It apparently just *makes sense* to people who already know the *what for*, and is hard for them to understand that this is not obvious for everyone else out there. – Rafael Eyng Dec 23 '14 at 12:36
  • 1
    I don't get it either and I don't agree with everything below*, nor is it complete (no references). Why I didn't accept an answer yet. * Of course there where it's not an opinion or personal practice. That, I get. – e-motiv Dec 23 '14 at 16:57

5 Answers5

53

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

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

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.

Exploring each item above:

  1. a set of (somehow) related projects

Eclipse seems to always be opened in association with a particular workspace, i.e., if you are in a workspace A and 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 B will now appear. So it seems that a project, to be open in Eclipse, MUST be associated to a workspace.

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. some configuration pertaining to all these projects

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.

  1. some settings for Eclipse itself

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.

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

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

Community
  • 1
  • 1
Rafael Eyng
  • 4,720
  • 2
  • 33
  • 34
  • 1
    I admit the last section needs some clarification. What is a sub-project, if not a project itself? How does these sub-projects make up for being used across different workspaces without using the whole parent project? I first need to find it out to improve the answer. – Rafael Eyng Dec 23 '14 at 20:51
  • 3
    This answer does contribute to the whole question. However, it's a bit folder focused and also misses some references and arguments. Nonetheless, it's informative. Sigh, these answers are getting difficult since all of them contribute, and I'm starting to think I will never be able to accept one answer. I hope nobody is a point freak here and we'll leave it without accepted answer? – e-motiv Jan 06 '15 at 16:47
  • 1
    I am from the "MS side" Solution / List of projects. Nothing more. Nothing to explain. Everything works fine. Open a solution, very easy: Open/Solution. Nothing more. Nothing to explain, Everything works fine. But this strange approach in Eclipse is driving me nuts. Usually I work on projects consisting of some sub-projects (UI-Layer, Domain-Layer, Test projects/Unit-Tests). In my opinion it makes sense to have one workspace for such a project (similar to yours, but I don't understand Item 4 ... ;-)) – hfrmobile Feb 08 '16 at 13:50
  • Item 4 was to show that different projects would have a separate workspace. Project 1 has several sub-projects, as does project 2. And project 1 and 2 have each one a separate workspace. – Rafael Eyng May 08 '16 at 03:37
  • Do we need to copy workspace folder as well along with project folders when copying/backing up the project? – Atul Jun 14 '22 at 07:53
39

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.resources plugin and it naturally by design makes sense.

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.

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

Abimaran Kugathasan
  • 31,165
  • 11
  • 75
  • 105
Duncan Krebs
  • 3,366
  • 2
  • 33
  • 53
  • The second part of your answer illustrates that my question is ambiguous. See the edit in the question I made-> I don't doubt workspaces are a good thing. – e-motiv Nov 27 '12 at 12:23
  • 1
    But thanks for your answer. It makes sense and at least I know how it is meant to be. Could you indulge me with more details and possibly a link (to eclipse) about your first sentence? – e-motiv Nov 27 '12 at 12:26
  • 6
    I disagree that the "point of a workspace is to group a set of related projects together that usually make up an application." Suppose I am developing two applications, should I have two workspaces? How annoying! All the custom perspectives, key bindings, auto-text, and other preferences are tied to the workspace. I will have to recreate them each time I begin a new application! In my opinion, you should have two workspaces: dev and latest released. Within the workspace, you create a WORKING SET for each application. This is how workspaces and working sets are meant to be used. – John Henckel Sep 16 '13 at 19:59
  • 2
    John, What do you do if you're two applications in your workspace are RCP applications for example and each require a different target platform, or a different java compiler compliance level Unless your applications require the exact same run-time configuration putting two apps in one workspace will cause issues. I understand having a common set of preferences you like to use, that is why there is a preference export/import feature so you can setup new workspaces and import your organizations or personal preferences and other settings. – Duncan Krebs Sep 21 '13 at 20:40
  • 1
    Interesting point @JohnHenckel! Though I have had my troubles with working sets. It seems they only work with some features of eclipse, though I guess you can all set them manually (as I did yesterday with tasks view, which gave me al tasks from all projects). Can you also do that for library functions, auto-completion, existing methods, etc. ? I am further interested how you use working sets. @DuncanKrebs, I didn't know the import/export feature of preferences. Thanks! That does solve a big deal of how to use workspaces. Thanks, both of you. And don't stop to throw in arguments / insights! – e-motiv Nov 01 '13 at 09:51
  • I am coming from Visual Studio. Where we just open a project. I have never understood why do I need to duplicate the existing code in the workspace by importing it. I guess there are some benefits that I don't see, yet, but your answers did not convince me. Workspaces just add one more obstacle to jump over, before you start being productive. Especially for beginners, every extra step of complexity is a reason to give up. Make it simple like visual studio. Developer doesn't need to know about environment setting. Visual studio also saves them without users' involvement... – Ozgur Ozturk Feb 12 '16 at 20:10
  • 1
    I just moved to eclipse. Previously I've been using this novel operating system concept called a "folder". A folder is a place on my file system I place a project. It can have sub-folders from there. You can even place multiple folders of related projects inside one parent folder. So, what would I do without Eclipse? I'd use a folder, a basic text editor, and compile and run from the command-line. So, your answer seems to expect we should all just know how useful "workspaces" are, but perhaps you should get acquainted with the "folder." – Gabriel Staples Mar 15 '18 at 23:35
  • 1
    Visual Studio uses a solution file that references many project files. Your projects aren't bound to the same folder as the solution. Visual Studio solution/project build structure is very similar to the Makefile/subfolder Makefile and CMake solutions. One file links to everything that is needed. And can filter things that are not needed. IMO, these are superior to Eclipse / Visual Studio Code workspaces. I agree, Netbeans projects are lacking a solution or parent makefile for subprojects. – TamusJRoyce Dec 02 '18 at 22:40
4

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.

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.

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!

Rafael Eyng
  • 4,720
  • 2
  • 33
  • 34
Lazaros Kosmidis
  • 729
  • 8
  • 8
  • What do you mean by DTLK? –  May 05 '16 at 20:03
  • When you abandoned the text editor in favor to an IDE the initial drive is the convenience of auto-complete and the view of your libraries (and docs ) in order to avoid syntax errors to say at least. In no circumstance you would jeopardize this functionality. – Lazaros Kosmidis May 07 '16 at 16:05
1

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.

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.

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).

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

pbyhistorian
  • 341
  • 2
  • 10
0

It's just a feature for structuring projects. Obviously Eclipse designers tried to avoid having global settings for Eclipse and decided to put them into workspace. Each Eclipse app depends on each workspace settings. Is it a good decision? I think it's not so. It lacks flexibility. It was naive to expect that global settings can be avoided. It doesn't allow you to have single projects (it can be a surprise for Eclipse designers but it happens quite often). But it still works. Many people use it. Sometimes they suffer but more frequently everything is ok.

ivanavdeyev
  • 1
  • 5