Espaces de travail Eclipse: pour quoi et pourquoi?
J'ai vu, lu et réfléchi à différentes manières d'utiliser des espaces de travail (par projet, par application (multi-tâches ou non), par langue de programme, par cible (développement Web, plugins, etc.), etc.) et I Je doute encore de la meilleure approche.
De toute façon, peut-on donner un aperçu détaillé, mais pas une page?
Pour ainsi dire, cela implique beaucoup de sous-questions, 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 d'Eclipse (et des espaces de travail), mais Je vais essayer de donner un exemple de ce que je cherche:
- Pourquoi?
- Pourquoi le développement Eclipse a-t-il été utilisé?
- Qu'en pensent les autres/la plupart des gens?
- Qu'est-ce que tu penses?
- ...?
- Pourquoi?
- Existe-t-il des conflits de configuration ou de partage des avantages?
- Des raisons d'espace de fichiers?
- 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 still autres, etc.)
Edit 2012-11-27: Ne vous méprenez pas. Je ne doute pas de l'utilisation de espaces de travail, je veux juste l’utiliser tel qu’il est censé être ou sinon si tout le monde le penserait mieux. Alors "pour quoi faire?" signifie: quelle est la meilleure utilisation? Et "Pourquoi?" vise en fait le "pour quoi?", en d’autres termes: dites-moi les raisons pour ta réponse.
Je vais vous donner ma vision de quelqu'un qui se sent très mal à l'aise dans le monde Java, et je suppose que c'est aussi votre cas.
Ce que c'est
Un espace de travail est un concept de regroupement:
- un ensemble de projets (en quelque sorte) liés
- une configuration relative à tous ces projets
- quelques réglages pour Eclipse lui-même
Cela se produit en créant un répertoire et en y insérant (vous n'avez pas à le faire, c'est fait pour vous) des fichiers qui parviennent à transmettre ces informations à Eclipse. Tout ce que vous avez à faire est explicitement de sélectionner le dossier dans lequel ces fichiers seront placés. Et ce dossier ne doit pas nécessairement être identique à l'endroit où vous mettez votre code source - de préférence, il ne le sera pas.
Explorer chaque article ci-dessus:
- 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 à espace de travail B se fermer et rouvrir. Tous les projets associés à espace de travail A (et apparaissant dans l'explorateur de projets) n'apparaîtront plus et les projets associés à espace de travail B apparaîtront à présent. Il semble donc qu’un projet, pour être ouvert dans Eclipse, MUST soit 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 certaine manière, une relation avec le chemin physique de vos projets sur votre disque (tout le monde sait comment? J’ai cherché à l’intérieur de l’espace de travail à la recherche d’un fichier pointant vers le chemin des projets, sans succès).
De cette façon, un projet peut être dans plus d'un espace de travail à la fois. Donc, il semble bien de garder votre espace de travail et votre code source séparés.
- 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, ils seront tous compilés avec le même compilateur Java.
- quelques réglages pour Eclipse lui-même
Certains éléments, tels que vos raccourcis clavier, sont également stockés au niveau de l’espace de travail. Ainsi, si vous définissez ce que ctrl + tab va basculer les onglets de manière intelligente (pas les empiler), cela ne sera lié à 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 deviez les exporter/importer entre les espaces de travail (si cela est vrai, ce IDE a été construit sur des locaux). Voici un lien sur ce .
Il semble également que les espaces de travail ne sont pas nécessairement compatibles entre les différentes versions d'Eclipse. Cet article vous suggère de nommer vos espaces de travail contenant le nom de la version Eclipse.
Et, plus important encore, une fois que vous avez sélectionné un dossier comme espace de travail, ne touchez aucun fichier à l'intérieur ou vous rencontrez 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 utiliser cela correctement, c'est pourquoi je cherchais une réponse - que j'essaie de rassembler ici)
Créez un dossier pour vos projets:
/projectsCréez un dossier pour chaque projet et regroupez les sous-projets du projet à l'intérieur:
/projects/proj1/subproj1_1/projects/proj1/subproj1_2/projects/proj2/subproj2_1Créez un dossier séparé pour vos espaces de travail:
/Eclipse-workspacesCré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 liés qui constituent généralement une application. La structure de l’espace de travail se résume au plug-in Eclipse.core.resources et, naturellement, elle est logique 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 la compilation en temps réel ou d'autres problèmes dans les projets situés dans le même espace de travail. La stratégie que je suggère est donc d’avoir différents espaces de travail pour différents projets mais sans un espace de travail dans Eclipse, il n’y aurait pas de concept de collection de projets et de configurations et c’est un outil IDE.
Si cela n’a aucun sens, demandez-vous comment Net Beans ou Visual Studio résout ce problème? C'est le même thème. Maven est un bon exemple. Archiver un groupe de projets Maven associés 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? Une application RCP peut être une bête différente en fonction de son utilisation, mais dans le vrai sens du terme IDE, je ne sais pas quelle solution serait meilleure 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 le fichier Eclipse lui-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 collecte toutes les configurations et les stocke dans cet espace de travail. Si un projet en conflit est présent dans le même espace de travail, vous risquez de perdre certaines fonctionnalités ou même la stabilité d'Eclipse.
Et en second lieu (secondaire) le point de la 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 d'ajuster davantage les relations de projet (en tant que bibliothèques, perspectives ctr), puis d'initier un ou plusieurs espaces de travail distincts. pourrait être approprié en fonction des habitudes de développement ou des é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 elle a cessé de fonctionner (correctement ou pas du tout) et la solution suggérée était de nettoyer les paramètres du plug-in équivalent de l'espace de travail actuel.
Personnellement, je me suis davantage penché sur la distinction des langues lorsqu'il s'agit de séparer des espaces de travail, ce qui est pertinent pour les problèmes connus liés à l'état actuel des plug-ins 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 à laquelle vous conservez vos projets ... Enfin, la vitesse de chargement et les performances sont un problème pourrait apparaître si de nombreux plug-ins (inutiles) sont chargés en raison de la présentation de projets non pertinents . il n’existe pas de solution unique, pas d’impression bleue maîtresse pour résoudre le problème. C'est quelque chose qui grandit avec l'expérience, Moins, c'est plus!
Bien que j'utilise Eclipse depuis des années, cette "réponse" n’est qu’une conjecture (que je vais essayer ce soir). Si le vote a été annulé, il est évident que je me trompe.
Oracle s'appuie sur CMake pour générer une "solution" Visual Studio pour son code source C de MySQL Connector. La solution contient des "projets" qui peuvent être compilés individuellement ou collectivement (par la solution). Chaque projet a son propre fichier Make, 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 de makefile associés (Eclipse), avec un projet maître dont les dépendances compilent les différents projets de makefile uniques comme pré-requis pour construire sa "Solution". (La structure de mon dossier serait comme décrit par @Rafael).
J'espère donc qu'un bon moyen d'utiliser les espaces de travail consiste à imiter la capacité de Visual Studio à combiner dissemblable projets dans une solution.