Widziałem, czytałem i myślałem o różnych sposobach korzystania z obszarów roboczych (na projekt, na aplikację (wieloaspektową lub nie), na język programu, na cel (tworzenie stron internetowych, wtyczki itp.) I tak dalej). wciąż wątpię, jakie jest najlepsze podejście.

Czy tak czy owak, czy możesz podać obszerny, ale nie obszerny wgląd w to?

Obejmuje to wiele pytań podrzędnych, że tak powiem, i nie znam wszystkich szczegółowych pytań podrzędnych, które powinienem zadać, ponieważ nie jestem pewien, czy nie znam wszystkich aspektów zaćmienia (i obszarów roboczych), ale Spróbuję podać przykład tego, czego szukam:

• Po co?
  
  • Do czego oznaczał rozwój zaćmienia?
  • Co myślą inni / większość ludzi?
  • Co myślisz?
  • ...?
• Czemu?
  
  • Czy istnieją konflikty konfiguracji a dzielenie się zaletami?
  • Jakieś powody związane z przestrzenią plików?
  • Występ?
  • ...?

Aha, i mówię o minimalnym przypadku użycia dla programisty, który używa różnych języków i protokołów, i niekoniecznie wszystkich z nich w jednym projekcie (np. Php, javascript i xml dla niektórych projektów, C # dla innych, java i SQL dla jeszcze inne itp.)

Edycja 2012-11-27: Nie zrozum mnie źle. Nie wątpię w korzystanie z obszarów roboczych, po prostu chcę z nich korzystać tak, jak powinny, lub w inny sposób, gdyby ktoś pomyślał, że to lepiej. Więc "po co?" oznacza: Jakie jest najlepsze zastosowanie? I dlaczego?" tak naprawdę kieruje się pytaniem „po co?”, innymi słowy: powiedz mi powody swojej odpowiedzi.

Przedstawię Ci moją wizję kogoś, kto czuje się bardzo nieswojo w świecie Javy, co, jak zakładam, dotyczy również Ciebie.

Co to jest

Obszar roboczy to koncepcja grupowania:

1. zbiór (w jakiś sposób) powiązanych projektów
2. pewna konfiguracja dotycząca wszystkich tych projektów
3. niektóre ustawienia samego Eclipse

Dzieje się tak, tworząc katalog i umieszczając w nim (nie musisz tego robić, to zrobione za Ciebie) pliki, które przekazują Eclipse te informacje. Wszystko, co musisz zrobić jawnie, to wybrać folder, w którym zostaną umieszczone te pliki. I ten folder nie musi być tym samym, w którym umieścisz kod źródłowy - najlepiej nie będzie.

Badanie każdego z powyższych elementów:

1. zbiór (w jakiś sposób) powiązanych projektów

Eclipse wydaje się zawsze otwierać w powiązaniu z określonym obszarem roboczym, tj. Jeśli jesteś w obszarze roboczym A i zdecydujesz się przełączyć na obszar roboczy B (Plik> Przełącz obszary robocze), Eclipse zamknie się i ponownie otworzy. Wszystkie projekty, które były powiązane z obszarem roboczym A (i pojawiały się w Eksploratorze projektów), nie będą już wyświetlane, a projekty skojarzone z obszarem roboczym B będą teraz wyświetlane. Wygląda więc na to, że projekt, który ma być otwarty w Eclipse, MUSI być powiązany z obszarem roboczym.

Zwróć uwagę, że nie oznacza to, że kod źródłowy projektu musi znajdować się wewnątrz obszaru roboczego. Obszar roboczy będzie w jakiś sposób mieć związek z fizyczną ścieżką projektów na dysku (ktoś wie jak? Szukałem w obszarze roboczym pliku wskazującego ścieżki projektów, bez powodzenia).

W ten sposób projekt może jednocześnie znajdować się w więcej niż 1 obszarze roboczym. Dlatego dobrze jest oddzielić obszar roboczy od kodu źródłowego.

2. pewna konfiguracja dotycząca wszystkich tych projektów

Słyszałem, że coś, jak wersja kompilatora Javy (na przykład 1.7, np. - nie wiem, czy słowo „wersja” jest tutaj słowem), jest konfiguracją na poziomie obszaru roboczego. Jeśli masz kilka projektów w swoim obszarze roboczym i skompilujesz je w Eclipse, wszystkie z nich zostaną skompilowane za pomocą tego samego kompilatora Java.

3. niektóre ustawienia samego Eclipse

Niektóre rzeczy, takie jak przypisania klawiszy, są również przechowywane na poziomie obszaru roboczego. Tak więc, jeśli zdefiniujesz, że ctrl + tab będzie przełączać karty w inteligentny sposób (nie ustawiając ich w stos), będzie to powiązane tylko z twoim bieżącym obszarem roboczym. Jeśli chcesz użyć tego samego powiązania klucza w innym obszarze roboczym (i myślę, że chcesz!), Wydaje się, że musisz je eksportować / importować między obszarami roboczymi (jeśli to prawda, to IDE zostało zbudowane na naprawdę dziwnych przesłankach). Oto link do tego .

Wydaje się również, że obszary robocze niekoniecznie są kompatybilne między różnymi wersjami Eclipse. W tym artykule sugeruje się nadawanie nazw obszarom roboczym zawierającym nazwę wersji Eclipse.

Co ważniejsze, po wybraniu folderu, który ma być obszarem roboczym, nie dotykaj żadnego pliku w nim zawartego, bo masz kłopoty.

Jak myślę, to dobry sposób na użycie tego

(właściwie pisząc to nie wiem jak to dobrze wykorzystać, dlatego szukałem odpowiedzi - którą próbuję zebrać tutaj)

1. Utwórz folder dla swoich projektów:
   /projects

2. Utwórz folder dla każdego projektu i zgrupuj w nim podprojekty projektów:
   /projects/proj1/subproj1_1
/projects/proj1/subproj1_2
/projects/proj2/subproj2_1

3. Utwórz oddzielny folder dla obszarów roboczych:
   /eclipse-workspaces

4. Twórz obszary robocze dla swoich projektów:
   /eclipse-workspaces/proj1
/eclipse-workspaces/proj2

Cały obszar roboczy polega na zgrupowaniu zestawu powiązanych projektów, które zwykle tworzą aplikację. Struktura obszaru roboczego sprowadza się do eclipse.core.resourceswtyczki i naturalnie z założenia ma sens.

Projekty mają naturę, konstruktorzy są dołączeni do określonych projektów, a gdy zmieniasz zasoby w jednym projekcie, możesz zobaczyć w czasie rzeczywistym kompilację lub inne problemy w projektach, które znajdują się w tym samym obszarze roboczym. Tak więc strategia, którą proponuję, to posiadanie różnych obszarów roboczych dla różnych projektów, nad którymi pracujesz, ale bez obszaru roboczego w zaćmieniu nie byłoby koncepcji zbioru projektów i konfiguracji, a przecież jest to narzędzie IDE.

Jeśli to nie ma sensu, zapytaj, jak rozwiązuje to Net Beans lub Visual Studio? To ten sam motyw. Dobrym przykładem jest Maven. Wyewidencjonowanie grupy powiązanych projektów Maven w obszarze roboczym umożliwia tworzenie i wyświetlanie błędów w czasie rzeczywistym. Jeśli nie miejsce do pracy, co jeszcze byś zaproponował? Aplikacja RCP może być inną bestią w zależności od tego, do czego jest używana, ale w prawdziwym sensie IDE nie wiem, co byłoby lepszym rozwiązaniem niż obszar roboczy lub kontekst projektów. Tylko moje myśli. - Duncan

Zasadniczo zakres obszaru roboczego jest podzielony na dwa punkty.

Pierwszy punkt (i podstawowy) to samo zaćmienie i jest związany z ustawieniami i konfiguracjami metadanych (ctr wtyczki). Za każdym razem, gdy tworzysz projekt, eclipse gromadzi wszystkie konfiguracje i przechowuje je w tym obszarze roboczym, a jeśli w jakiś sposób w tym samym obszarze roboczym obecny jest projekt będący w konflikcie, możesz stracić część funkcjonalności, a nawet stabilność samego zaćmienia.

I drugi (drugorzędny) punkt strategii rozwoju, który można przyjąć. Gdy podstawowy zakres zostanie osiągnięty (i opanowany) i istnieje potrzeba dalszych dostosowań dotyczących relacji w projekcie (takich jak biblioteki, perspektywy ctr), należy zainicjować oddzielne obszary robocze, które mogą być odpowiednie w oparciu o nawyki programistyczne lub możliwe „zachowania” języka / struktury. DLTK na przykład to bestia, która powinna znajdować się w osobnej klatce. Wiele skarg na forach przestało działać (poprawnie lub wcale), a sugerowanym rozwiązaniem było wyczyszczenie ustawień odpowiedniej wtyczki z bieżącego obszaru roboczego.

Osobiście odkryłem, że bardziej skłaniam się do rozróżnienia językowego, jeśli chodzi o oddzielne obszary robocze, co ma znaczenie dla znanych problemów związanych z obecnym stanem wtyczek. Najlepiej utrzymuję je w minimalnej liczbie, ponieważ prowadzi to do mniejszej frustracji, gdy projekty stają się ... obfite, a kontrola wersji nie jest jedyną wersją, którą przechowujesz. Wreszcie, szybkość ładowania i wydajność to problem, który może się pojawić, jeśli ładowanych jest wiele (niepotrzebnych) wtyczek z powodu prezentów nieistotnych projektów. Konkluzja; nie ma jednego rozwiązania dla każdego, nie ma wzorcowego niebieskiego druku, który rozwiązuje problem. To coś, co rośnie wraz z doświadczeniem, chociaż mniej znaczy więcej!

Chociaż używam Eclipse od lat, ta „odpowiedź” jest tylko przypuszczeniem (którego spróbuję dziś wieczorem). Jeśli zostanie uznany za nieistniejący, to oczywiście się mylę.

Oracle polega na CMake w zakresie generowania „rozwiązania” Visual Studio dla ich kodu źródłowego MySQL Connector C. W ramach Rozwiązania znajdują się „Projekty”, które mogą być kompilowane indywidualnie lub zbiorczo (przez Rozwiązanie). Każdy projekt ma swój własny plik makefile, który kompiluje swoją część rozwiązania z ustawieniami innymi niż inne projekty.

Podobnie, mam nadzieję, że obszar roboczy Eclipse może pomieścić moje powiązane projekty plików makefile (Eclipse), z głównym projektem, którego zależności kompilują różne unikalne projekty makefile jako warunki wstępne do zbudowania jego „rozwiązania”. (Struktura mojego folderu byłaby taka, jak opisuje @Rafael).

Mam więc nadzieję, że dobrym sposobem korzystania z obszarów roboczych jest emulacja zdolności programu Visual Studio do łączenia różnych projektów w rozwiązanie.