Je vais vous fournir ma vision de quelqu'un qui se sent très mal à l'aise dans le monde Java, ce que je suppose est également votre cas.

Qu'est-ce que c'est

Un espace de travail est un concept de regroupement:

1. un ensemble de projets (en quelque sorte) liés
2. quelques configurations relatives à tous ces projets
3. quelques paramètres pour Eclipse lui-même

Cela se produit en créant un répertoire et en y mettant (vous n'avez pas à le faire, c'est fait pour vous) fichiers qui parviennent à dire à Eclipse ces informations. Tout ce que vous avez à faire explicitement est de sélectionner le dossier où ces fichiers seront placés. Et ce dossier n'a pas besoin d'être le même où vous mettez votre code source - préférentiellement, il ne le sera pas.

Explorer chaque élément ci-dessus:

1. un ensemble de projets (en quelque sorte) liés

Eclipse semble toujours être ouvert en association avec un espace de travail particulier, c'est-à-dire si vous êtes dans un espace de travail A et décidez de passer à workspace B (Fichier > Changer d'espace de travail), Eclipse se fermera et rouvrira. Tous les projets associés àworkspace A (et apparaissant dans l'Explorateur de projets) n'apparaîtront plus et les projets associés àworkspace B apparaîtront désormais. Il semble donc qu'un projet, pour être ouvert dans Eclipse, DOIT être associé à un espace de travail.

Notez que cela ne signifie pas que le code source du projet doit être à l'intérieur de l'espace de travail. L'espace de travail aura, en quelque sorte, une relation avec le chemin physique de vos projets sur votre disque (quelqu'un sait comment? J'ai regardé dans l'espace de travail à la recherche d'un fichier pointant vers les chemins des projets, sans succès).

De cette façon, un projet peut se trouver dans plus d'un espace de travail à la fois. Il semble donc bon de garder votre espace de travail et votre code source séparés.

1. quelques configurations relatives à tous ces projets

Je entendu que quelque chose, comme la version du compilateur Java (comme 1.7, par exemple - je ne sais pas si "version" est le mot ici), est une configuration au niveau de l'espace de travail. Si vous avez plusieurs projets dans votre espace de travail et que vous les compilez dans Eclipse, tous seront compilés avec le même compilateur Java.

1. quelques paramètres pour Eclipse lui-même

Certaines choses comme vos liaisons de touches sont également stockées au niveau de l'espace de travail. Donc, si vous définissez que ctrl + tab va basculer onglets de manière intelligente (ne pas les empiler), cela ne sera lié qu'à votre espace de travail actuel. Si vous voulez utiliser la même liaison de clé dans un autre espace de travail (et je pense que vous voulez!), il semble que vous devez les exporter/importer entre les espaces de travail (si c'est vrai, cetE a été construit sur des locaux vraiment étranges). Voici un lien sur cette.

Il semble également que les espaces de travail ne soient pas nécessairement compatibles entre les différentes versions d'Eclipse. Cet article suggère que vous nommez vos espaces de travail contenant le nom de la version Eclipse.

Et, plus important encore, une fois que vous avez choisi un dossier pour être votre espace de travail, ne touchez aucun fichier à l'intérieur ou vous avez des problèmes.

Comment je pense est un bon moyen de l'utiliser

(en fait, au moment où j'écris ceci, je ne sais pas comment l'utiliser dans le bon sens, c'est pourquoi je cherchais une réponse – que j'essaie d'assembler ici)

1. Créer un dossier pour votre projets:
   /projects

2. Créer un dossier pour chaque projet de groupe et des projets de sous-projets à l'intérieur d'elle:
   /projects/proj1/subproj1_1
/projects/proj1/subproj1_2
/projects/proj2/subproj2_1

3. Créer un dossier séparé pour vos espaces de travail:
   /eclipse-workspaces

4. Créer des espaces de travail pour vos projets:
   /eclipse-workspaces/proj1
/eclipse-workspaces/proj2

Le but d'un espace de travail est de regrouper un ensemble de projets connexes qui constituent généralement une application. Le cadre de l'espace de travail se résume au plugin eclipse.core.resources et il est naturellement logique par sa conception.

Les projets ont des natures, les constructeurs sont attachés à des projets spécifiques et lorsque vous modifiez des ressources dans un projet, vous pouvez voir en temps réel la compilation ou d'autres problèmes dans les projets qui se trouvent dans le même espace de travail. Donc, la stratégie que je suggère est d'avoir différents espaces de travail pour différents projets sur lesquels vous travaillez, mais sans espace de travail dans eclipse, il n'y aurait pas de concept de collection de projets et de configurations et après tout, c'est un outil ID.

Si cela n'a pas de sens, demandez comment Net Beans ou Visual Studio aborde cela? C'est le même thème. Maven est un bon exemple, la vérification d'un groupe de projets maven dans un espace de travail permet de développer et de voir les erreurs en temps réel. Si ce n'est pas un espace de travail, que suggérez-vous d'autre? Une application RCP peut être un bête différente en fonction de ce à quoi elle sert, mais dans le vrai sens de l'E, je ne sais pas quelle serait une meilleure solution qu'un espace de travail ou un contexte de projets. Juste mes pensées. - Duncan

Fondamentalement la portée de l'espace de travail(s) est divisée en deux points.

Le premier point (et primaire) est l'éclipse elle-même et est liée aux configurations de paramètres et de métadonnées (plugin ctr). Chaque fois que vous créez un projet, eclipse collecte toutes les configurations et les stocke sur cet espace de travail et si d'une manière ou d'une autre dans le même espace de travail un projet en conflit est présent, vous risquez de perdre certaines fonctionnalités ou même la stabilité d'eclipse lui-même.

Et deuxième (secondaire) le point de la stratégie de développement on peut adopter. Une fois que la portée principale est atteinte (et maîtrisée) et qu'il est nécessaire de procéder à d'autres ajustements concernant les relations de projet (bibliothèques, ctr perspectives), alors lancer des espaces de travail séparés pourrait être approprié en fonction des habitudes de développement ou des "comportements"possibles de langage/frameworks. DLTK par exemple est une bête qui devrait être contenue dans une cage séparée. Beaucoup de plaintes sur les forums pour cela a cessé de fonctionner (correctement ou pas du tout) et la solution suggérée était de nettoyer les paramètres du plugin équivalent de l'espace de travail courant.

Personnellement, je me suis retrouvé à me pencher davantage sur la distinction de langue en ce qui concerne les espaces de travail séparés, ce qui est pertinent pour les problèmes connus liés à l'état actuel des plugins utilisés. De préférence, je les garde dans le nombre minimum car cela conduit à moins de frustration lorsque les projets sont devenus... beaucoup et le contrôle de version n'est pas la seule version que vous gardez vos projets. Enfin, la vitesse de chargement et les performances sont un problème qui peut survenir si de nombreux plugins (inutiles) sont chargés en raison de la présentation de projets non pertinents. Bottom line; il n'y a pas de solution unique à chacun, pas de master blue print qui résout le problème. C'est quelque chose qui grandit avec l'expérience, Moins est plus quand même!!

Bien que j'utilise Eclipse depuis des années, cette "réponse" n'est qu'une conjecture (que je vais essayer ce soir). S'il est rejeté-voté hors de l'existence, alors évidemment je me trompe.

Oracle s'appuie sur CMake pour générer une "solution" Visual Studio pour leur code source MySQL Connector C. Dans la Solution se trouvent des "Projets" qui peuvent être compilés individuellement ou collectivement (par la Solution). Chaque projet a son propre makefile, compilant sa partie de la solution avec des paramètres qui sont différent des autres Projets.

De même, j'espère qu'un espace de travail Eclipse pourra contenir mes projets makefile associés (Eclipse), avec un projet maître dont les dépendances compilent les différents projets makefile uniques en tant que pré-requis pour construire sa "Solution". (Ma structure de dossier serait comme @ Rafael décrit).

J'espère donc qu'une bonne façon d'utiliser les espaces de travail est d'émuler la capacité de Visual Studio à combiner des projets différents en une solution.