Ich habe verschiedene Arten der Verwendung von Arbeitsbereichen (pro Projekt, pro Anwendung (mehrfach oder nicht), pro Programmiersprache, pro Ziel (Webentwicklung, Plugins usw.) usw. gesehen, gelesen und darüber nachgedacht Ich bezweifle immer noch, was der beste Ansatz ist.

Kannst du trotzdem einen ausführlichen, aber keinen seitenlangen Einblick in diese geben?

Dies beinhaltet sozusagen viele Unterfragen, und ich kenne nicht alle spezifischen Unterfragen, die ich stellen sollte, weil ich nicht sicher bin, ob ich nicht alle Aspekte von Eclipse (und Arbeitsbereichen) kenne, aber Ich werde versuchen, ein Beispiel dafür zu geben, wonach ich suche:

• Wozu?
  
  • Wofür bedeutete die Eclipse-Entwicklung die Verwendung?
  • Was denken andere / die meisten Leute?
  • Was denken Sie?
  • ...?
• Warum?
  
  • Gibt es Konfigurationskonflikte oder gemeinsame Vorteile?
  • Irgendwelche Gründe für den Dateibereich?
  • Performance?
  • ...?

Oh, und ich spreche vom minimalen Anwendungsfall für einen Entwickler, der verschiedene Sprachen und Protokolle verwendet, und NICHT unbedingt alle in einem Projekt (z. B. PHP, Javascript und XML für einige Projekte, C # für andere, Java und SQL für Still andere usw ..)

Edit 2012-11-27: Versteh mich nicht falsch. Ich bezweifle nicht die Verwendung von Arbeitsbereichen, ich möchte sie nur so verwenden, wie sie sein soll oder auf andere Weise, wenn jemand es besser finden würde. Also "wofür?" bedeutet: Was ist die beste Verwendung? Und warum?" Ziele auf das "Wofür?", mit anderen Worten: Sagen Sie mir die Gründe für Ihre Antwort.

Ich werde Ihnen meine Vision von jemandem vermitteln, der sich in der Java-Welt sehr unwohl fühlt. Ich gehe davon aus, dass dies auch Ihr Fall ist.

Was es ist

Ein Arbeitsbereich ist ein Konzept der Gruppierung:

1. eine Reihe von (irgendwie) verwandten Projekten
2. Einige Konfigurationen für all diese Projekte
3. Einige Einstellungen für Eclipse selbst

Dies geschieht, indem Sie ein Verzeichnis erstellen und darin Dateien ablegen (Sie müssen es nicht tun, es wird für Sie erledigt), die es schaffen, Eclipse diese Informationen mitzuteilen. Sie müssen lediglich explizit den Ordner auswählen, in dem diese Dateien abgelegt werden sollen. Und dieser Ordner muss nicht derselbe sein, in dem Sie Ihren Quellcode abgelegt haben - vorzugsweise nicht.

Erkunden Sie jeden der oben genannten Punkte:

1. eine Reihe von (irgendwie) verwandten Projekten

Eclipse scheint immer in Verbindung mit einem bestimmten Arbeitsbereich geöffnet zu sein. Wenn Sie sich also in einem Arbeitsbereich A befinden und zum Arbeitsbereich B wechseln (Datei> Arbeitsbereiche wechseln ), wird Eclipse sich selbst schließen und erneut öffnen. Alle Projekte, die dem Arbeitsbereich A zugeordnet waren (und im Projektexplorer angezeigt wurden), werden nicht mehr angezeigt, und Projekte, die dem Arbeitsbereich B zugeordnet sind, werden jetzt angezeigt. So scheint es , dass ein Projekt, in Eclipse , offen zu sein, muss zu einem Arbeitsbereich zugeordnet werden.

Beachten Sie, dass dies nicht bedeutet, dass sich der Projektquellcode im Arbeitsbereich befinden muss. Der Arbeitsbereich hat irgendwie eine Beziehung zum physischen Pfad Ihrer Projekte auf Ihrer Festplatte (weiß jemand wie? Ich habe im Arbeitsbereich nach einer Datei gesucht, die auf die Projektpfade verweist, ohne Erfolg).

Auf diese Weise kann sich ein Projekt in mehr als einem Arbeitsbereich gleichzeitig befinden. Es scheint also gut, Ihren Arbeitsbereich und Ihren Quellcode getrennt zu halten.

2. Einige Konfigurationen für all diese Projekte

Ich habe gehört, dass etwas wie die Java-Compiler-Version (wie 1.7, z. B. - ich weiß nicht, ob 'version' hier das Wort ist) eine Konfiguration auf Arbeitsbereichsebene ist. Wenn Sie mehrere Projekte in Ihrem Arbeitsbereich haben und diese in Eclipse kompilieren, werden alle mit demselben Java-Compiler kompiliert.

3. Einige Einstellungen für Eclipse selbst

Einige Dinge wie Ihre Tastenkombinationen werden auch auf Arbeitsbereichsebene gespeichert. Wenn Sie also definieren, dass Strg + Tab die Registerkarten auf intelligente Weise wechselt (nicht stapelt), ist dies nur an Ihren aktuellen Arbeitsbereich gebunden. Wenn Sie dieselbe Schlüsselbindung in einem anderen Arbeitsbereich verwenden möchten (und ich denke, Sie möchten!), Müssen Sie sie anscheinend zwischen Arbeitsbereichen exportieren / importieren (wenn dies zutrifft, wurde diese IDE über einige wirklich seltsame Prämissen erstellt). Hier ist ein Link dazu .

Es scheint auch, dass Arbeitsbereiche nicht unbedingt zwischen verschiedenen Eclipse-Versionen kompatibel sind. In diesem Artikel wird vorgeschlagen , dass Sie Ihre Arbeitsbereiche mit dem Namen der Eclipse-Version benennen.

Und was noch wichtiger ist: Wenn Sie einen Ordner als Arbeitsbereich ausgewählt haben, berühren Sie dort keine Datei, oder Sie haben Probleme.

Wie ich denke, ist ein guter Weg, um es zu benutzen

(Eigentlich weiß ich beim Schreiben nicht, wie ich das gut gebrauchen soll, deshalb habe ich nach einer Antwort gesucht - die ich hier zusammenbauen möchte)

1. Erstellen Sie einen Ordner für Ihre Projekte:
   /projects

2. Erstellen Sie für jedes Projekt einen Ordner und gruppieren Sie die Unterprojekte der Projekte darin:
   /projects/proj1/subproj1_1
/projects/proj1/subproj1_2
/projects/proj2/subproj2_1

3. Erstellen Sie einen separaten Ordner für Ihre Arbeitsbereiche:
   /eclipse-workspaces

4. Erstellen Sie Arbeitsbereiche für Ihre Projekte:
   /eclipse-workspaces/proj1
/eclipse-workspaces/proj2

Der Sinn eines Arbeitsbereichs besteht darin, eine Reihe verwandter Projekte zu gruppieren, aus denen normalerweise eine Anwendung besteht. Das Workspace-Framework hängt vom eclipse.core.resourcesPlugin ab und ist natürlich von Natur aus sinnvoll.

Projekte haben Natur, Builder sind an bestimmte Projekte gebunden, und wenn Sie Ressourcen in einem Projekt ändern, können Sie in Echtzeit Kompilierungen oder andere Probleme in Projekten sehen, die sich im selben Arbeitsbereich befinden. Die Strategie, die ich vorschlage, besteht darin, unterschiedliche Arbeitsbereiche für unterschiedliche Projekte zu haben, an denen Sie arbeiten. Ohne einen Arbeitsbereich in Eclipse gibt es jedoch kein Konzept für eine Sammlung von Projekten und Konfigurationen, und schließlich handelt es sich um ein IDE-Tool.

Wenn das keinen Sinn ergibt, fragen Sie, wie Net Beans oder Visual Studio dies angehen. Es ist das gleiche Thema. Maven ist ein gutes Beispiel. Wenn Sie eine Gruppe verwandter Maven-Projekte in einem Arbeitsbereich auschecken, können Sie Fehler in Echtzeit entwickeln und anzeigen. Wenn nicht ein Arbeitsbereich, was würden Sie sonst noch vorschlagen? Eine RCP-Anwendung kann ein anderes Tier sein, je nachdem, wofür sie verwendet wird, aber im eigentlichen Sinne der IDE weiß ich nicht, was eine bessere Lösung wäre als ein Arbeitsbereich oder ein Kontext von Projekten. Nur meine Gedanken. - Duncan

Grundsätzlich ist der Umfang der Arbeitsbereiche in zwei Punkte unterteilt.

Der erste Punkt (und der primäre Punkt) ist die Sonnenfinsternis selbst und hängt mit den Einstellungen und Metadatenkonfigurationen zusammen (Plugin ctr). Jedes Mal, wenn Sie ein Projekt erstellen, sammelt Eclipse alle Konfigurationen und speichert sie in diesem Arbeitsbereich. Wenn sich im selben Arbeitsbereich ein Konfliktprojekt befindet, verlieren Sie möglicherweise einige Funktionen oder sogar die Stabilität von Eclipse selbst.

Und zweitens (sekundär) den Punkt der Entwicklungsstrategie, den man annehmen kann. Sobald der primäre Bereich erreicht (und gemeistert) ist und weitere Anpassungen in Bezug auf die Projektbeziehungen (wie Bibliotheken, Perspektiven ctr) erforderlich sind, können separate Arbeitsbereiche initiiert werden, die auf Entwicklungsgewohnheiten oder möglichen Sprach- / Framework- "Verhaltensweisen" basieren. DLTK zum Beispiel ist ein Tier, das in einem separaten Käfig enthalten sein sollte. Viele Beschwerden in Foren funktionierten nicht mehr (richtig oder gar nicht) und es wurde vorgeschlagen, die Einstellungen des entsprechenden Plugins aus dem aktuellen Arbeitsbereich zu entfernen.

Persönlich habe ich mich mehr auf die Sprachunterscheidung gestützt, wenn es um separate Arbeitsbereiche geht, die für bekannte Probleme relevant sind, die mit dem aktuellen Status der verwendeten Plugins verbunden sind. Am besten halte ich sie in der Mindestanzahl, da dies zu weniger Frustration führt, wenn die Projekte ... reichlich sind und die Versionskontrolle nicht die einzige Version ist, in der Sie Ihre Projekte behalten. Schließlich ist die Ladegeschwindigkeit und -leistung ein Problem, das auftreten kann, wenn viele (unnötige) Plugins aufgrund von Geschenken irrelevanter Projekte geladen werden. Endeffekt; Es gibt keine Lösung für jeden, keine Master-Blaupause, die das Problem löst. Es ist etwas, das mit der Erfahrung wächst, aber weniger ist mehr!

Obwohl ich Eclipse seit Jahren benutze, ist diese "Antwort" nur eine Vermutung (die ich heute Abend versuchen werde). Wenn es aus der Existenz herabgestimmt wird, dann liege ich offensichtlich falsch.

Oracle verlässt sich auf CMake, um eine Visual Studio- "Lösung" für den MySQL Connector C-Quellcode zu generieren. Innerhalb der Lösung befinden sich "Projekte", die einzeln oder gemeinsam (von der Lösung) zusammengestellt werden können. Jedes Projekt verfügt über ein eigenes Makefile, das seinen Teil der Lösung mit Einstellungen kompiliert, die sich von den anderen Projekten unterscheiden.

Ebenso hoffe ich, dass ein Eclipse-Arbeitsbereich meine zugehörigen Makefile-Projekte (Eclipse) mit einem Master-Projekt enthalten kann, dessen Abhängigkeiten die verschiedenen eindeutigen Makefile-Projekte als Voraussetzungen für die Erstellung seiner "Lösung" kompilieren. (Meine Ordnerstruktur wäre wie von @Rafael beschrieben).

Ich hoffe, dass eine gute Möglichkeit zur Verwendung von Arbeitsbereichen darin besteht, die Fähigkeit von Visual Studio zu emulieren, unterschiedliche Projekte zu einer Lösung zu kombinieren .