Espaces de travail Eclipse: pour quoi et pourquoi?

133

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.

eclipse workspace e-motiv
la source
14
Je ne comprends toujours pas. Il semble tout simplement logique pour les gens qui connaissent déjà le pour quoi , et il est difficile pour eux de comprendre que ce n'est pas évident pour tout le monde là - bas.
Rafael Eyng
Je ne comprends pas non plus et je ne suis pas d'accord avec tout ce qui suit *, ni complet (pas de références). Pourquoi je n'ai pas encore accepté de réponse. * Bien sûr là où ce n'est pas une opinion ou une pratique personnelle. Ça, je comprends.
e-motiv
J'ai essayé d'y répondre, ce n'est pas une très bonne réponse mais je pense que je peux construire dessus
Rafael Eyng

Réponses:

43

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.

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

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

Rafael Eyng
la source
1
J'admets que la dernière section doit être clarifiée. Qu'est-ce qu'un sous-projet, sinon un projet lui-même? Comment ces sous-projets compensent-ils leur utilisation dans différents espaces de travail sans utiliser l'ensemble du projet parent? Je dois d'abord le découvrir pour améliorer la réponse.
Rafael Eyng
2
Cette réponse contribue à toute la question. Cependant, il est un peu concentré sur les dossiers et manque également certaines références et arguments. Néanmoins, c'est informatif. Soupir, ces réponses deviennent difficiles car elles contribuent toutes, et je commence à penser que je ne pourrai jamais accepter une seule réponse. J'espère que personne n'est un maniaque des points ici et nous le laisserons sans réponse acceptée?
e-motiv
Salut @ RU-Bn. Je ne suis pas d'accord. J'aimerais juste pouvoir expliquer ce qu'est un espace de travail Eclipse, pour être sûr de le savoir.
Rafael Eyng
Hé, je ne voulais pas dire cette dernière question à personne en particulier. C'était juste en général. J'aurais peut-être dû l'écrire en commentaire en haut.
e-motiv
@ RU-Bn, absolument, je ne l'ai pas mal pris. Peut-être que je me suis mal exprimé.
Rafael Eyng
37

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

Duncan Krebs
la source
1
Mais merci pour votre réponse. Cela a du sens et au moins je sais comment cela est censé être. Pourriez-vous me donner plus de détails et éventuellement un lien (pour éclipser) sur votre première phrase?
e-motiv
5
Je ne suis pas d'accord sur le fait que «le but d'un espace de travail est de regrouper un ensemble de projets connexes qui constituent généralement une application». Supposons que je développe deux applications, dois-je avoir deux espaces de travail? Comme c'est ennuyeux! Toutes les perspectives personnalisées, combinaisons de touches, texte automatique et autres préférences sont liées à l'espace de travail. Je vais devoir les recréer à chaque fois que je lance une nouvelle application! À mon avis, vous devriez avoir deux espaces de travail: dev et dernière version. Dans l'espace de travail, vous créez un WORKING SET pour chaque application. C'est ainsi que les espaces de travail et les ensembles de travail doivent être utilisés.
John Henckel
2
John, que faites-vous si vous êtes deux applications dans votre espace de travail sont des applications RCP par exemple et que chacune nécessite une plate-forme cible différente, ou un niveau de conformité du compilateur Java différent Sauf si vos applications nécessitent exactement la même configuration d'exécution en mettant deux applications dans un espace de travail causera des problèmes. Je comprends que vous ayez un ensemble commun de préférences que vous aimez utiliser, c'est pourquoi il existe une fonction d'exportation / importation de préférences afin que vous puissiez configurer de nouveaux espaces de travail et importer vos organisations ou préférences personnelles et autres paramètres.
Duncan Krebs
1
Point intéressant @JohnHenckel! Bien que j'aie eu mes problèmes avec les ensembles de travail. Il semble qu'ils ne fonctionnent qu'avec certaines fonctionnalités d'Eclipse, bien que je suppose que vous pouvez tous les définir manuellement (comme je l'ai fait hier avec la vue des tâches, qui m'a donné toutes les tâches de tous les projets). Pouvez-vous également faire cela pour les fonctions de bibliothèque, l'auto-complétion, les méthodes existantes, etc.? Je suis également intéressé par la manière dont vous utilisez les ensembles de travail. @DuncanKrebs, je ne connaissais pas la fonction d'importation / exportation des préférences. Merci! Cela résout une grande partie de la façon d'utiliser les espaces de travail. Merci à vous deux. Et ne vous arrêtez pas pour ajouter des arguments / idées!
e-motiv
1
Je viens de passer à l'éclipse. Auparavant, j'utilisais ce nouveau concept de système d'exploitation appelé «dossier». Un dossier est un endroit sur mon système de fichiers où je place un projet. Il peut y avoir des sous-dossiers à partir de là. Vous pouvez même placer plusieurs dossiers de projets associés dans un dossier parent. Alors, que ferais-je sans Eclipse? J'utiliserais un dossier, un éditeur de texte de base, et compilerais et exécuterais à partir de la ligne de commande. Donc, votre réponse semble supposer que nous devrions tous savoir à quel point les «espaces de travail» sont utiles, mais peut-être devriez-vous vous familiariser avec le «dossier».
Gabriel Staples
3

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!

Lazaros Kosmidis
la source
Qu'entendez-vous par DTLK?
Lorsque vous avez abandonné l'éditeur de texte au profit d'un IDE, le lecteur initial est la commodité de l'auto-complétion et la vue de vos bibliothèques (et documents) afin d'éviter des erreurs de syntaxe au moins. En aucun cas vous ne compromettriez cette fonctionnalité.
Lazaros Kosmidis
1

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.

pbyhistorien
la source