J'ai vu, lu et pensé à différentes manières d'utiliser les espaces de travail (par projet, par application (multi-actifs ou non), par langage de programme, par cible (développement web, plugins, ..), etc.) et je je doute toujours de la meilleure approche.

Pouvez-vous de toute façon donner un aperçu détaillé, mais pas d'une page de long, à ce sujet?

Cela implique beaucoup de sous-questions, pour ainsi dire, et je ne connais pas toutes les sous-questions spécifiques que je devrais poser, car je ne suis pas sûr de ne pas connaître tous les aspects de l'éclipse (et des espaces de travail), mais Je vais essayer de donner un exemple de ce que je recherche:

• Pourquoi?
  
  • À quoi le développement d'éclipse signifiait-il qu'il devait être utilisé?
  • Que pensent les autres / la plupart des gens?
  • Qu'est-ce que tu penses?
  • ...?
• Pourquoi?
  
  • Existe-t-il des conflits de configuration ou des mérites de partage?
  • Des raisons d'espace fichier?
  • Performance?
  • ...?

Oh, et je parle du cas d'utilisation minimum pour un développeur qui utilise différents langages et protocoles, et PAS nécessairement tous dans un projet (par exemple, php, javascript et xml pour certains projets, C # pour d'autres, java et SQL pour toujours autres, etc.)

Edit 2012-11-27: Ne vous méprenez pas. Je ne doute pas de l'utilisation des espaces de travail, je veux juste l'utiliser tel qu'il est censé être ou autrement si quelqu'un le pense mieux. Alors "pour quoi faire?" signifie: Quelle est la meilleure utilisation? Et pourquoi?" cible en fait le "pourquoi?", en d'autres termes: dites-moi les raisons de votre réponse.

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

Ce que c'est

Un espace de travail est un concept de regroupement:

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

Cela se produit en créant un répertoire et en y mettant (vous n'êtes pas obligé de le faire, c'est fait pour vous) des fichiers qui parviennent à communiquer ces informations à Eclipse. Tout ce que vous avez à faire explicitement est de sélectionner le dossier dans lequel ces fichiers seront placés. Et ce dossier n'a pas besoin d'être le même que celui où vous avez placé votre code source - de préférence, 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 que si vous êtes dans un espace de travail A et décidez de passer à l' espace de travail B (Fichier> Changer d'espace de travail), Eclipse se fermera et rouvrira. Tous les projets associés à l' espace de travail A (et apparaissant dans l'explorateur de projet) n'apparaîtront plus et les projets associés à l' espace de travail 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, d'une manière ou d'une autre, une relation avec le chemin physique de vos projets sur votre disque (n'importe qui sait comment? J'ai regardé à l'intérieur de 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 séparer votre espace de travail et votre code source.

2. une configuration relative à tous ces projets

J'ai entendu dire 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.

3. certains paramètres pour Eclipse lui-même

Certaines choses comme vos raccourcis clavier sont également stockées au niveau de l'espace de travail. Donc, si vous définissez que ctrl + tab changera d'onglet de manière intelligente (sans les empiler), cela ne sera lié qu'à votre espace de travail actuel. Si vous souhaitez utiliser la même liaison de clé dans un autre espace de travail (et je pense que vous le souhaitez!), Il semble que vous deviez les exporter / importer entre les espaces de travail (si c'est vrai, cet IDE a été construit sur des locaux vraiment étranges). Voici un lien à ce sujet .

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

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

Comment je pense que c'est une bonne façon de l'utiliser

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

1. Créez un dossier pour vos projets:
   /projects

2. Créez un dossier pour chaque projet et regroupez les sous-projets des projets à l'intérieur:
   /projects/proj1/subproj1_1
/projects/proj1/subproj1_2
/projects/proj2/subproj2_1

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

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

L'intérêt d'un espace de travail est de regrouper un ensemble de projets associés qui constituent généralement une application. Le cadre de l'espace de travail se résume au eclipse.core.resourcesplugin et il est naturellement logique de par sa conception.

Les projets ont des natures, les générateurs 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 un espace de travail en éclipse, il n'y aurait pas de concept de collection de projets et de configurations et après tout, c'est un outil IDE.

Si cela n'a pas de sens, demandez comment Net Beans ou Visual Studio résout cela? C'est le même thème. Maven est un bon exemple, l'extraction d'un groupe de projets maven connexes dans un espace de travail vous permet de développer et de voir les erreurs en temps réel. Si ce n'est pas un espace de travail, que suggéreriez-vous d'autre? Une application RCP peut être une bête différente en fonction de son utilisation, mais dans le vrai sens IDE, 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 des espaces de travail est divisée en deux points.

Le premier point (et principal) est l'éclipse elle-même et est lié aux paramètres et aux configurations de métadonnées (plugin ctr). Chaque fois que vous créez un projet, eclipse recueille 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é de l'éclipse lui-même.

Et en second lieu (secondaire) le point de stratégie de développement que l'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 à des ajustements supplémentaires concernant les relations du projet (comme les bibliothèques, les perspectives ctr), alors initier un ou plusieurs espaces de travail séparés pourraient être appropriés en fonction des habitudes de développement ou d'éventuels «comportements» de langage / cadres. DLTK par exemple est une bête qui devrait être contenue dans une cage séparée. Beaucoup de plaintes sur les forums car 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 actuel.

Personnellement, je me suis davantage penché sur la distinction des langues lorsqu'il s'agit d'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 les nombres minimums car cela conduit à moins de frustration lorsque les projets sont devenus ... abondants et le contrôle de version n'est pas la seule version que vous conservez vos projets. Enfin, la vitesse de chargement et les performances sont un problème qui pourrait 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 schéma directeur qui résout le problème. C'est quelque chose qui grandit avec l'expérience, mais moins c'est plus!

Bien que j'utilise Eclipse depuis des années, cette "réponse" n'est que conjecture (que je vais essayer ce soir). Si elle est rejetée, alors évidemment je me trompe.

Oracle s'appuie sur CMake pour générer une «solution» Visual Studio pour son 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 différents de ceux 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 uniques makefile comme pré-requis pour construire sa «solution». (Ma structure de dossiers serait comme @Rafael le décrit).

J'espère donc qu'un bon moyen d'utiliser les espaces de travail consiste à émuler la capacité de Visual Studio à combiner des projets différents dans une solution.