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

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?

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.

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.

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

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;
}

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.

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

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.

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.

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

Po prostu skopiuj katalogi

${old_workspace}/.metadata/.plugins

z istniejącego projektu do nowego.

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

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.