Espaces de travail Eclipse : Pour quoi faire et pourquoi ?

Question

J'ai vu, lu et réfléchi à différentes façons d'utiliser les espaces de travail (par projet, par application (multi-accessoires ou non), par langage de programmation, par cible (développement web, plugins,..), et ainsi de suite) et je doute toujours de la meilleure approche.

Quelqu'un peut-il donner un aperçu détaillé, mais pas long d'une page, de cette question ?

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

• Pour quoi faire ?
• À quoi l'équipe de développement d'Eclipse s'attendait-elle à ce qu'il soit utilisé ?
  • Que pensent les autres/la plupart des gens ?
  • Qu'en pensez-vous ?
  • ... ?
• Pourquoi ?
• Y a-t-il des conflits de configuration par rapport aux avantages du partage ?
• Des raisons d'espace de fichiers ?
• Performance ?
• ... ?

Je parle du cas d'utilisation minimum pour un développeur qui utilise différents langages et protocoles, no nécessairement tous dans un même projet (par exemple Php, Javascript et XML pour certains projets, C# pour d'autres, Java et SQL pour d'autres encore, etc )

Editer 2012-11-27 : Ne vous méprenez pas. Je ne doute pas de l'utilité des Workspaces, je veux juste l'utiliser comme il est censé l'être ou sinon si quelqu'un pense que c'est mieux. Donc "pour quoi faire ?" signifie : Quelle est la meilleure utilisation ? Et "pourquoi ?" vise en fait le "pourquoi ?", en d'autres termes : dites-moi les raisons de votre réponse. de votre réponse.

Answer 1

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

Ce que c'est

Un espace de travail est un concept de regroupement :

1. un ensemble de projets liés (d'une manière ou d'une autre)
2. une configuration relative à tous ces projets
3. quelques paramètres pour Eclipse lui-même

Cela se fait en créant un répertoire et en y plaçant (vous n'avez pas à le faire, c'est fait pour vous) des fichiers qui se chargent d'indiquer ces informations à Eclipse. Tout ce que vous avez à faire explicitement est de sélectionner le dossier où ces fichiers seront placés. Et ce dossier ne doit pas nécessairement être le même que celui où vous placez votre code source - de préférence, il ne le sera pas.

En explorant chaque élément ci-dessus :

1. un ensemble de projets liés (d'une manière ou d'une autre)

Eclipse semble toujours être ouvert en association avec un espace de travail particulier. espace de travail A et décide de passer à espace de travail B (Fichier > Changer d'espace de travail), Eclipse se ferme et se rouvre. Tous les projets qui étaient associés à espace de travail A (et qui apparaissaient dans l'Explorateur de projets) n'apparaîtront plus et les projets associés à des espace de travail B apparaîtra maintenant. Il semble donc qu'un projet, pour être ouvert dans Eclipse, MUST être associé à un espace de travail.

Notez que cela ne signifie pas que le code source du projet doit se trouver dans 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 (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 judicieux 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 le mot "version" est approprié 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, ils seront tous compilés avec le même compilateur Java.

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

Certaines choses, comme les liaisons de touches, sont également stockées au niveau de l'espace de travail. Ainsi, si vous définissez que ctrl+tab permet de changer d'onglet de manière intelligente (sans les empiler), cela ne sera lié qu'à votre espace de travail actuel. Si vous voulez utiliser la même combinaison de touches dans un autre espace de travail (et je pense que vous le voulez !), il semble que vous devez les exporter/importer entre les espaces de travail (si c'est vrai, cet IDE a été construit sur des prémisses vraiment étranges). Voici un lien sur 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 avec le nom de la version d'Eclipse.

Et, plus important encore, une fois que vous avez choisi un dossier comme espace de travail, ne touchez à aucun fichier qui s'y trouve, sinon vous risquez d'avoir des problèmes.

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

(en fait, à l'heure où j'écris ces lignes, 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-y les sous-projets des projets :
   /projects/proj1/subproj1_1
/projects/proj1/subproj1_2
/projects/proj2/subproj2_1

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

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

Answer 2

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 à eclipse.core.resources et cela a naturellement du sens.

Les projets ont une nature, les constructeurs sont attachés à des projets spécifiques et lorsque vous modifiez les ressources d'un projet, vous pouvez voir en temps réel les problèmes de compilation ou autres dans les projets qui sont dans le même espace de travail. La stratégie que je suggère est donc d'avoir différents espaces de travail pour les 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 IDE.

Si cela n'a pas de sens, demandez comment Net Beans ou Visual Studio aborde cette question. C'est le même thème. Maven est un bon exemple, le fait d'extraire 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 sens d'un véritable IDE, je ne vois pas quelle serait une meilleure solution qu'un espace de travail ou un contexte de projets. C'est juste mon avis. - Duncan

Answer 3

Fondamentalement, l'étendue de l'espace de travail est divisée en deux points.

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

Et deuxièmement (secondaire) le point de la stratégie de développement que l'on peut adopter. Une fois que le champ d'application primaire est atteint (et maîtrisé) et qu'il est nécessaire de procéder à d'autres ajustements concernant les relations entre les projets (comme les bibliothèques, les perspectives, etc.), il peut être approprié d'initier un ou plusieurs espaces de travail séparés en fonction des habitudes de développement ou des "comportements" possibles des langages et des cadres. DLTK par exemple est une bête qui devrait être contenue dans une cage séparée. Beaucoup de plaintes sur les forums pour avoir 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 trouvé plus enclin à la distinction linguistique lorsqu'il s'agit d'espaces de travail séparés, ce qui est pertinent pour les problèmes connus qui viennent avec 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 beaucoup de plugins (inutiles) sont chargés en raison de la présence de projets non pertinents. En résumé, il n'y a pas de solution unique pour chaque problème, pas de schéma directeur qui résout tous les problèmes. C'est quelque chose qui se développe avec l'expérience, Mais moins, c'est mieux !

Answer 4

Bien que j'utilise Eclipse depuis des années, cette "réponse" n'est qu'une conjecture (que je vais essayer ce soir). Si elle fait l'objet d'un vote négatif, alors il est évident que j'ai tort.

Oracle s'appuie sur CMake pour générer une "Solution" Visual Studio pour le code source C de son MySQL Connector. Cette solution contient des "projets" qui peuvent être compilés individuellement ou collectivement (par la solution). Chaque projet possède son propre fichier 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 connexes (Eclipse), avec un projet maître dont les dépendances compilent les divers projets makefile uniques comme pré-requis pour construire sa "solution". (Ma structure de dossier serait comme @Rafael le 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 dissimilaire Les projets en une solution.