Jak udostępniać konfigurację Eclipse w różnych obszarach roboczych

133

Używam Eclipse (PDT) jako podstawowego IDE na różnych komputerach. (jak w domu, laptopie, w biurze itp.). Jak mogę pragmatycznie udostępniać konfigurację Eclipse i projektu między wieloma komputerami? Czy powinienem je kontrolować w wersji, czy jest na to prostszy sposób?

Jak zapewnić używanie tej samej dobrej i starej, mimo tak aktualnej konfiguracji wszystkich komputerów?

erenon
źródło
Miałem różnego rodzaju problemy z udostępnianiem kodu w jednym obszarze roboczym za pomocą Dropbox. Skłoniłbym się do posiadania wielu obszarów roboczych, po jednym dla każdego komputera, i synchronizowania grupy obszarów roboczych za pomocą Dropbox.
djangofan
3
Stare pytanie, które znam, ale dla potomnych uważam, że ten post na blogu jest bardzo przydatny: mcuoneclipse.wordpress.com/2012/04/04/ (To nie jest mój post :-)
Stewart
W środowiskach Windows zawsze występują komplikacje. Sprawdzanie ustawień obszaru roboczego w kontroli źródła nie jest odpowiedzią. Ustawienia kontroli źródła są częścią ustawień obszaru roboczego.
chris topinka
1
@ zb226: done ....
erenon

Odpowiedzi:

179

Udostępnianie specyficznych ustawień zaćmienia w obszarach roboczych :

  1. Iść do ${old_workspace}/.metadata/.plugins/org.eclipse.core.runtime/.settings
  2. Skopiuj wszystko z powyższego katalogu do ${new_workspace}/.metadata/.plugins/org.eclipse.core.runtime/.settings

Zapewni to, że ${new_workspace}ma taką samą konfigurację jak${old_workspace}

Mam nadzieję że to pomoże. Zaktualizuj w przypadku jakichkolwiek problemów.

peakit
źródło
8
Osobiście mam te foldery połączone symbolicznie z dropboxem, a także profile RSE są połączone symbolicznie. Ogólną konfigurację ustawień zaćmienia można również wyeksportować z ide
Anton S
5
Zacznę od tego, ale niestety poza tym katalogiem jest o wiele więcej ustawień, które chciałbym zsynchronizować.
David Harkness
@DavidHarkness: proszę wyjaśnić - jakie ustawienia - gdzie? Mógłbyś zamieścić tutaj odpowiedź - pytam między innymi: „czy byłoby bezpiecznie i wystarczająco mocno połączyć \.metadata\.plugins\org.eclipse.core.runtime\.settings directory?” - to peakit: to nie jest takie proste - ${old_workspace}/.metadata/.plugins/org.eclipse.core.runtime/.settingszawiera również ustawienia obszaru roboczego i ma inne osobliwości - zobacz moją analizę tutaj
Mr_and_Mrs_D
Aby skopiować folder, użyj Robocopy: stackoverflow.com/questions/472692/…
weberjn
1
Aby zachować synchronizację, rozważ Unison: cis.upenn.edu/~bcpierce/unison
Alice Purcell
115

Inną opcją jest eksport / import:

  1. Z istniejącego obszaru roboczego File->Export...->General->Preferences zaznacz opcję Eksportuj wszystko i wybierz plik, w którym chcesz je zapisać (na przykład prefs.epf)
  2. Uruchom Eclipse w nowym obszarze roboczym, File->Import...->General->Preferenceswybierz plik (prefs.epf), zaznacz opcję importuj wszystko

To zadziałało świetnie dla oryginalnego autora tej wskazówki: zaimportował formatowanie kodu, styl kodu, repozytoria svn, preferencje jres.

Edycja: na Eclipse Juno działa to słabo. Niektóre preferencje nie są po cichu przenoszone, np. Zapisywanie.

Anthony Dahanne
źródło
2
Działa również z Eclipse STS (Spring Tool Suite) 3.4
рüффп
1
Pracował nad Eclipse Luna
GP cyborg
9

To stosunkowo nowy projekt, ale wygląda na to, że Eclipse Oomph powstał właśnie z tego powodu. Za pomocą tego narzędzia można stworzyć unikalną konfigurację, którą można udostępniać innym. Nie korzystałem (jeszcze), ale planuję:

https://projects.eclipse.org/projects/tools.oomph

HDave
źródło
Profile Yatta bazują na instalatorze Oomph / Eclipse i sprawiają, że udostępnianie jest nieco łatwiejsze.
Bernhard Stadler
1
@BernhardStadler Yatta nie przenosi preferencji.
ThomasMcLeod
Yatta może zapamiętać domyślne wartości preferencji - preferencje obszaru roboczego można zapisać za pomocą rejestratora preferencji, a do preferencji projektu nie potrzebujesz żadnych dodatkowych narzędzi, ponieważ możesz je dodać do swojego SCM. Głównym zamierzonym przypadkiem użycia jest konfiguracja obszaru roboczego do programowania jednym kliknięciem dla zespołów w celu zminimalizowania czasu konfiguracji, ale możliwa jest również synchronizacja profili prywatnych między różnymi komputerami. Nigdy sam tego nie próbowałem, ale według ich strony internetowej prawdopodobnie jest możliwe zastosowanie aktualizacji z profili online, więc powinno być możliwe użycie prywatnych profili online jako mechanizmu synchronizacji.
Bernhard Stadler
7

Musiałem pracować jednocześnie na wielu obszarach roboczych i za każdym razem, gdy tworzę nowy obszar roboczy, trzeba było ustawić wiele preferencji. Utworzyłem obszar roboczy szablonu i utworzyłem wszystkie wymagane ustawienia w tym obszarze roboczym szablonu. Za każdym razem, gdy tworzę nowy obszar roboczy, tworzę łącze simlink {new_workspace}/.metadata/.plugins/org.eclipse.core.runtime/.settingsdo wskaż {template_workspace}/.metadata/.plugins/org.eclipse.core.runtime/.settings. Tak więc, gdy edytujesz dowolne preferencje w dowolnym obszarze roboczym, zostaną one zreplikowane we wszystkich innych obszarach roboczych.

Utworzyłem ten alias funkcji w moim .profile, więc po utworzeniu nowego obszaru roboczego uruchamiam tę funkcję w moim wierszu polecenia z moją nową nazwą obszaru roboczego jako argumentem, aby utworzyć łącze.

function eclset(){
    present_dir=`pwd`;
    cd  {parent_to_workspace}/$1/.metadata/.plugins/org.eclipse.core.runtime ; 
    rm -rf .settings ; 
    ln -s {parent_to_workspace}/template/.metadata/.plugins/org.eclipse.core.runtime/.settings .settings;
    cd $present_dir;
}
Mowgli
źródło
Właściwie to też chciałem zrobić (w systemie Windows) - ale są komplikacje: zobacz moją odpowiedź tutaj
Mr_and_Mrs_D
4

W rzeczywistości można ustawić wiele ustawień specyficznych dla projektu, które można sprawdzić w kontroli źródła. W przypadku małych projektów działa to naprawdę dobrze. W przypadku większych projektów zdecydowaliśmy się na jeden plik, którego używaliśmy we wszystkich naszych projektach i wpisaliśmy go do osobnego projektu „zasobów”, który zawierał elementy potrzebne programistom do rozpoczęcia pracy nad naszym projektem. Obejmuje to również takie rzeczy, jak licencje i inne wymagane pliki.

Topher Fangio
źródło
45
Chociaż jest to zaakceptowana odpowiedź, zdecydowanie powinieneś przewinąć w dół i spojrzeć na inne odpowiedzi, ponieważ zawierają dodatkowe informacje.
Topher Fangio
1
@erenon - Czy możesz odznaczyć tę odpowiedź jako zaakceptowaną i wybrać inną, bardziej odpowiednią? Pozostałe zawierają znacznie więcej informacji, ale nie mogę usunąć tej odpowiedzi, jeśli została zaakceptowana.
Topher Fangio,
3

Począwszy od Eclipse Neon (i być może również Marsa), możesz skopiować następujące dwa katalogi, aby udostępniać swój stół roboczy i ustawienia / preferencje w różnych obszarach roboczych:

    [workspace]/.metadata/.plugins/org.eclipse.core.runtime/.settings
    [workspace]/.metadata/.plugins/org.eclipse.e4.workbench
Antonio Malcolm
źródło
Czy to naprawdę zostało wprowadzone w Neonie? Czy istnieje dziennik zmian / plik Readme lub inne informacje, które to potwierdzają?
Danijel
Zazwyczaj programiści mają własne repozytorium GIT i nie są udostępniane, więc lista jest następująca: 1. [obszar roboczy] /. Metadata / .plugins / org.eclipse.core.runtime / .settings - z wyjątkiem [obszaru roboczego] /. Metadata / .plugins /org.eclipse.core.runtime/.settings/org.eclipse.egit.core.prefs 2. [obszar roboczy] /. metadata / .plugins / org.eclipse.e4.workbench
Timo Riikonen,
2

Tu są dwa pytania. Po pierwsze, istnieją definicje projektów, pliki .project i ustawienia specyficzne dla projektu. Osobiście lubię te w mojej kontroli źródła, ponieważ znacznie ułatwia sprawdzanie projektu i konfigurowanie IDE.

Po drugie, masz ustawienia obszaru roboczego. W tym obszarze zobaczysz wiele pytań. Proponuję przyjrzeć się Pulse : jest to ulepszona dystrybucja Eclipse, która może między innymi zapisywać ustawienia obszaru roboczego i synchronizować je z wieloma maszynami lub członkami zespołu.

zvikico
źródło
1

Możesz także skopiować pliki .prefs z ${old_workspace}/.metadata/.plugins/org.eclipse.core.runtime/.settings do folderu o nazwie .settings w folderze głównym projektu, a następnie dodać go do SVN (lub CVS lub ...)

W ten sposób ustawienia zostaną rozesłane do wszystkich programistów wraz z kodem źródłowym podczas aktualizacji.

Evvo
źródło
0

miałem ten sam problem.

moje podejście: przechowywanie danych projektu w katalogu zarządzanym przez owncloud

Projekt X jest tworzony na stacji roboczej A, z niestandardową ścieżką wskazującą na nowy podkatalog w mojej własnej hierarchii Cloud. Domyślny obszar roboczy nadal rezyduje w systemie plików A.

Kiedy siedzę na stacji roboczej BI, otwórz domyślny lokalny obszar roboczy (lokalny na B) i utwórz nowy projekt, korzystając z istniejących źródeł w „zsynchronizowanym” katalogu ownCloud.

Po prostu kliknij przycisk odśwież za każdym razem, gdy uruchomisz zaćmienie i masz aktualne dane projektu. Synchronizacja przebiega w tle automagicznie, więc uważaj, kiedy zakończysz pracę nad zamknięciem zaćmienia i daj ownCloud szansę na przesłanie nowych plików na serwer ownCloud.

Tomcat lub inne serwery działają lokalnie, konfiguracja jest kopiowana ręcznie między maszynami za pośrednictwem scp. Dzieje się tak tylko wtedy, gdy nastąpią zmiany w konfiguracji serwera, co nie jest zbyt częste.

Nie miałem żadnych problemów ze zgodnością, używając NEON 2 (arch linux) i NEON 3 (pobierz wersję uruchomioną na debianie stretch) z różnymi JDK.

Pozdrawiam Armin

armin
źródło
0

Po prostu skopiuj katalogi

${old_workspace}/.metadata/.plugins

z istniejącego projektu do nowego.

To działało dobrze w (raczej prostych) projektach PHP.

schogol
źródło
0

Możesz użyć Eclipstyle do klonowania preferencji jednego obszaru roboczego do innych obszarów roboczych. Możesz także wyeksportować swoje preferencje i sklonować je później.

Utku Ufuk
źródło