Przestrzenie robocze Eclipse: po co i dlaczego?

133

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.

e-motyw
źródło
14
Nadal nie rozumiem. Najwyraźniej ma to sens dla ludzi, którzy już wiedzą, po co i trudno im zrozumieć, że nie jest to oczywiste dla wszystkich innych.
Rafael Eyng
Ja też tego nie rozumiem i nie zgadzam się ze wszystkim poniżej *, ani nie jest kompletne (brak odniesień). Dlaczego jeszcze nie przyjąłem odpowiedzi. * Oczywiście tam, gdzie nie jest to opinia ani osobista praktyka. To rozumiem.
e-motiv
Próbowałem na nie odpowiedzieć, nie jest to zbyt dobra odpowiedź, ale myślę, że mogę na niej zbudować
Rafael Eyng,

Odpowiedzi:

43

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.

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

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

Rafael Eyng
źródło
1
Przyznaję, że ostatnia sekcja wymaga wyjaśnienia. Czym jest podprojekt, jeśli nie sam projekt? Jak te podprojekty wpływają na używanie w różnych obszarach roboczych bez używania całego projektu nadrzędnego? Najpierw muszę się tego dowiedzieć, aby poprawić odpowiedź.
Rafael Eyng,
2
Ta odpowiedź przyczynia się do całego pytania. Jednak jest trochę skoncentrowany na folderach, a także pomija niektóre odniesienia i argumenty. Niemniej jednak jest to pouczające. Wzdychaj, te odpowiedzi stają się coraz trudniejsze, ponieważ wszystkie z nich wnoszą swój wkład i zaczynam myśleć, że nigdy nie będę w stanie zaakceptować jednej odpowiedzi. Mam nadzieję, że nikt nie jest tu maniakiem punktacji i zostawimy to bez zaakceptowanej odpowiedzi?
e-motiv
Hej @ RU-Bn. Nie jestem w tym punkcie. Chciałbym tylko móc wyjaśnić, czym jest Eclipse Workspace, żeby mieć pewność, że go znam.
Rafael Eyng
Hej, nie miałem na myśli tego ostatniego pytania do nikogo w szczególności. To było tylko ogólne. Może powinienem był napisać to jako komentarz na górze.
e-motiv
@ RU-Bn, absolutnie, nie odebrałem tego źle. Może właśnie źle się wyraziłem.
Rafael Eyng
37

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

Duncan Krebs
źródło
1
Ale dzięki za odpowiedź. To ma sens i przynajmniej wiem, jak to ma być. Czy mógłbyś mi pozwolić na więcej szczegółów i ewentualnie link (do zaćmienia) na temat twojego pierwszego zdania?
e-motiv
5
Nie zgadzam się, że „celem obszaru roboczego jest zgrupowanie zestawu powiązanych projektów, które zwykle składają się na aplikację”. Załóżmy, że tworzę dwie aplikacje, czy powinienem mieć dwa obszary robocze? Jakie to irytujące! Wszystkie niestandardowe perspektywy, skróty klawiszowe, tekst automatyczny i inne preferencje są powiązane z obszarem roboczym. Będę musiał je odtworzyć za każdym razem, gdy zacznę nową aplikację! Moim zdaniem powinieneś mieć dwie przestrzenie robocze: dev i najnowszą wersję. W obszarze roboczym tworzysz ZESTAW ROBOCZY dla każdej aplikacji. W ten sposób mają być używane obszary robocze i zestawy robocze.
John Henckel
2
John, Co zrobisz, jeśli masz dwie aplikacje w swoim obszarze roboczym, na przykład aplikacje RCP i każda z nich wymaga innej platformy docelowej lub innego poziomu zgodności kompilatora java Chyba że twoje aplikacje wymagają dokładnie tej samej konfiguracji czasu wykonywania, w której są dwie aplikacje jeden obszar roboczy spowoduje problemy. Rozumiem, że mam wspólny zestaw preferencji, których lubisz używać, dlatego istnieje funkcja eksportu / importu preferencji, dzięki której możesz skonfigurować nowe obszary robocze i zaimportować swoje organizacje lub preferencje osobiste i inne ustawienia.
Duncan Krebs
1
Ciekawy punkt @JohnHenckel! Chociaż miałem kłopoty z pracującymi zestawami. Wygląda na to, że działają tylko z niektórymi funkcjami zaćmienia, chociaż myślę, że wszystkie możesz ustawić ręcznie (tak jak wczoraj zrobiłem to z widokiem zadań, który dał mi wszystkie zadania ze wszystkich projektów). Czy możesz to również zrobić dla funkcji bibliotecznych, automatycznego uzupełniania, istniejących metod itp.? Interesuje mnie również sposób korzystania z zestawów roboczych. @DuncanKrebs, nie znałem funkcji importu / eksportu preferencji. Dzięki! To rozwiązuje wiele kwestii związanych z korzystaniem z obszarów roboczych. Dzięki Wam obojgu. I nie przestawaj wrzucać argumentów / spostrzeżeń!
e-motiv
1
Właśnie przeniosłem się do zaćmienia. Wcześniej korzystałem z tej nowatorskiej koncepcji systemu operacyjnego zwanej „folderem”. Folder to miejsce w moim systemie plików, w którym umieszczam projekt. Może mieć stamtąd podfoldery. Możesz nawet umieścić wiele folderów powiązanych projektów w jednym folderze nadrzędnym. Więc co bym zrobił bez Eclipse? Używałbym folderu, podstawowego edytora tekstu i kompilowałbym i uruchamiał z wiersza poleceń. Twoja odpowiedź wydaje się więc zakładać, że wszyscy powinniśmy wiedzieć, jak przydatne są „przestrzenie robocze”, ale być może powinieneś zapoznać się z „folderem”.
Gabriel Staples
3

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!

Lazaros Kosmidis
źródło
Co masz na myśli mówiąc DTLK?
Kiedy porzuciłeś edytor tekstu na rzecz IDE, początkowym dyskiem jest wygoda autouzupełniania i widok twoich bibliotek (i dokumentów), aby przynajmniej uniknąć błędów składniowych. W żadnym wypadku nie zagroziłbyś tej funkcjonalności.
Lazaros Kosmidis
1

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.

pbyhistorian
źródło