Eclipse: Czy powinienem utworzyć obszar roboczy dla każdego projektu?

Po prostu zastanawiam się, czy najlepiej umieścić wszystkie moje projekty Eclipse w jednym obszarze roboczym, czy też zrobić 1 obszar roboczy na 1 projekt. Jestem tylko samodzielnym programistą, mniej więcej dla hobby, ale aplikacje, które tworzę, w rzeczywistości mają wersje produkcyjne, które działają na dość częstych zadaniach cron, więc jest to prawie jak amatorskie środowisko produkcyjne.

Jedyne problemy, które do tej pory zauważyłem, dotyczą eksportowania plików JAR, mam potencjał do dołączania plików źródłowych z innych projektów, co wydaje się być bałagan.

Kiedyś utrzymywałem oddzielne obszary robocze, ale zmęczyły mnie trudności z utrzymaniem spójnych ustawień między nimi. Teraz tworzę zestawy robocze dla różnych projektów i zmieniam bieżący zestaw roboczy okna, aby odfiltrować wszystko oprócz tego, nad czym chcę pracować. Jak dotąd działało to dobrze dla mnie.

Ponieważ każdy projekt może mieć wiele zestawów roboczych, a zestaw roboczy okna może być dowolną kombinacją zestawów roboczych, w ten sposób dość łatwo jest zobaczyć tylko to, czego chcesz w danym momencie.

Tworzę obszary robocze Eclipse wokół produktów, ponieważ dla mnie produkt może mieć wiele projektów, na przykład skompilowanie podstawowych bibliotek w jednym słoiku w projekcie, jest to używane w innych projektach.

Jeśli chodzi o środowisko produkcyjne, chciałbyś, aby produkty działały w różnych strukturach katalogów, znacznie czystszych w ten sposób. W eclipse obszar roboczy tworzy katalog z nazwą obszaru roboczego. Dlatego twórz obszary robocze w oparciu o produkt / aplikację, a nie jeden lub więcej projektów w nich.

Jeśli projekty są ze sobą powiązane (tj. Mają wzajemne zależności), to dość często sensowne jest umieszczenie ich w tym samym obszarze roboczym. To samo dotyczy również sytuacji, gdy pracujesz nad kilkoma projektami, aby rozwiązać powiązany problem.

W przeciwnym razie zmarnujesz dużo czasu na niepotrzebne zmienianie obszarów roboczych, zwłaszcza gdy IDE natychmiast pokaże ci wpływ zmian w jednym projekcie na inny.

Nie tylko utrzymuję oddzielne obszary robocze dla każdego projektu, ale także przechowuję osobne kopie Eclipse. Dzieje się tak, ponieważ zazwyczaj muszę odkładać projekty na długi czas i wracać do nich (z niewielkim wyprzedzeniem), a oni absolutnie muszą budować. Nie mogę ryzykować, że jakaś wtyczka, którą zainstalowałem dla mojego najnowszego projektu (opartego na mavenie), będzie kolidować z procesem budowania jednego ze starszych systemów (opartych na mrówkach). Dla przypomnienia , dokumentuję środowisko zaćmienia dla tych starszych systemów, ale nie mam czasu na majstrowanie przy zaćmieniu podczas łatania błędu produkcyjnego.

Używałbym oddzielnych obszarów roboczych dla różnych „grup” projektów. Na przykład możesz chcieć połączyć swój główny projekt aplikacji ORAZ projekt testów jednostkowych razem w tym samym obszarze roboczym.

Może mam pecha, ale Eclipse często (powiedzmy raz w miesiącu) umiera podczas uruchamiania, zazwyczaj na etapie „Inicjowanie narzędzi w języku Java”. Wydaje się, że zalecanym rozwiązaniem jest utworzenie nowego obszaru roboczego. Jeśli masz wszystkie swoje projekty w jednym obszarze roboczym, może to być uciążliwe. Myślę, że mniejsze obszary robocze mogą oznaczać, że awaria jest mniej prawdopodobna.

Ponieważ Preferencje są specyficzne dla obszaru roboczego, mam zwykle otwarty ogromny obszar roboczy - jestem zbyt leniwy, aby synchronizować niektóre ustawienia między obszarami roboczymi (np. Repozytoria ...).

Z drugiej strony, zbyt wiele projektów otwartych w jednym obszarze roboczym może spowolnić Eclipse - więc muszę przynajmniej zamknąć projekty, nad którymi nie pracuję. Zarządzam wieloma względnie krótkoterminowymi projektami (maksymalnie miesiąc) w Eclipse, które znajdują się w tym samym obszarze roboczym (iw większości przypadków w tym samym repozytorium), więc ta konfiguracja zapewnia mi większą elastyczność.

Jeśli masz kilka powiązanych ze sobą projektów, trzymaj je w tym samym obszarze roboczym. Jeśli możesz zidentyfikować grupę projektów, które są zawsze używane razem, ale grupy są używane niezależnie, umieść takie zestawy projektów w różnych obszarach roboczych. W takim przypadku powinna to być struktura logiczna.

Mamy sytuację, w której mamy kilka projektów, niektóre w oddziałach, co szczerze mówiąc jest zbyt niepraktyczne, aby trzymać się tego samego obszaru roboczego - a zestawy robocze to żart. Niestety. Również otwarte projekty, których nie używasz, mogą zostać przypadkowo wybrane z menu zakończenia itp. Podatny na błędy.

Naprawdę fajną funkcją dla nas było dodanie zespołu -> zestawy projektów (w Eclipse 3.3, jak sądzę), ponieważ pozwoliło nam to mieć pojedynczy plik opisujący wiele projektów składających się na całą aplikację, który można zaimportować w Eclipse z Team -> Importuj. Potrzebujesz konkretnego projektu? Sprawdź to z CVS, zlokalizuj w nim plik projectSet.psf i zaimportuj TO.

Okazało się to dla nas dobre.

Mam jeden obszar roboczy na typ projektu. Np. Zwykła Java, aplikacja internetowa, Python itp.

Powodem jest to, że mogę udostępniać biblioteki, które są podobne, bez kopiowania ich ani wskazywania na nie. Poza tym zamykam niepowiązane projekty przed zaćmieniem, aby uniknąć bałaganu.

Mam wszystkie swoje projekty w jednym miejscu i używam zestawów roboczych do zarządzania nimi.

Zależy od Ciebie! Zawsze uważałem, że utrzymywanie powiązanych wersji różnych projektów, które należą do tego samego wydania w danym obszarze roboczym, jest czystszym podejściem. W ten sposób mogłem przełączać się między obszarami roboczymi, ilekroć potrzebuję odnieść się do czegoś w oddzielnej wersji, i wrócić do obszaru roboczego z bieżącą wersją. Oszczędza mi to również kłopotów z wyewidencjonowywaniem lub przeglądaniem repozytorium.

Możesz również pamiętać, że możesz otworzyć wiele wystąpień zaćmienia, o ile patrzą one na różne obszary robocze. Nie jestem pewien, czy to dla ciebie ważne, ale lubię to robić od czasu do czasu.

Lubię korzystać z kilku oddzielonych obszarów roboczych (różniących się w zależności od typu projektu), które importują projekty z różnych lokalizacji. Łatwe przenoszenie rzeczy bez tworzenia wielu podobnych obszarów roboczych. Dobrze też gra z moim SCM.

Zależy od tego, ile projektów pracujesz? Jeśli pracujesz nad wieloma projektami, użyłbym tego samego obszaru roboczego, ponieważ jeśli używasz kilku, łatwo zapomnisz, co jest gdzie i co może być frustrujące. Jednak zawsze używam innego obszaru roboczego dla różnych języków programowania, dzięki czemu jest to mniej zagmatwane, gdy jesteś w obszarze roboczym JAVA, myślisz, że JAVA: D