.classpath i .project - sprawdzać kontrolę wersji czy nie?

Uruchamiam projekt Java typu open source, który składa się z wielu modułów w drzewie zależności. Wszystkie te moduły są podkatalogami w repozytorium subversion. Nowicjuszom w naszym projekcie jest dużo pracy, aby ustawić to wszystko ręcznie w czasie zaćmienia.

Nie wszyscy nasi programiści używają Eclipse. Niemniej jednak rozważamy po prostu sprawdzenie plików .classpath i .project, aby pomóc nowicjuszom w rozpoczęciu. Czy to dobry pomysł? Czy może to prowadzić do ciągłych konfliktów w tych plikach? Czy istnieje alternatywny sposób na ułatwienie konfiguracji projektu podczas zaćmienia?

Zdecydowanie tak, jak powiedziałem w " Czy trzymasz pliki projektu pod kontrolą wersji? "

„Załaduj, skonfiguruj, idź”.

Ale ... w rzeczywistości jest to prawdą tylko dla ostatnich ustawień Eclipse3.5, gdzie ścieżki budowania obsługują ścieżki względne :

A Eclipse3.6 byłby lepszy, ponieważ obsługuje ścieżki względne dla zmiennych ścieżek w Linked Resources:

(od 3.6M5)

Zdecydowanie nie - dystrybucja plików projektu przez Subversion jest ogólnie okropnym pomysłem. Zwłaszcza, że ​​ktoś może je w jakiś dziwny sposób zmodyfikować. Dobra strona w dokumentacji projektu to znacznie lepszy pomysł. Nasz projekt ma również wiele modułów i złożoną konfigurację. Utworzyliśmy stronę konfluencji opisującą, jak rozpocząć projekt w każdym popularnym środowisku IDE - IntelliJ, Eclipse, NetBeans. Plik README w Subversion zawiera te same informacje.

Głosuję na nie, ale to dlatego, że generalnie generowałbym te pliki od mavena

Z mojego doświadczenia, z wyłączeniem ograniczonych przypadków, w których dotyczą ustawień czysto lokalnych, wszystko powinno być pod kontrolą źródła. Prawo kontroli źródła głosi, że każdy, kto wycofa się, powinien oczekiwać, że wszystko, co zostanie wprowadzone, zadziała. Niestety zaćmienie często powoduje takie rzeczy .classpath:

    <classpathentry kind="con" 
      path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.launching.macosx.MacOSXType/Java SE 7"/>

Więc na moim Macu to działa, a może ktoś na Macu ma to samo JRE, ale to nie zadziała dla nikogo innego.

Nie ma też łatwego sposobu na obejście tego. Eclipse zawsze to doda. CHCĘ mieć tam plik .classpath, ponieważ w naszym folderze lib znajdują się pliki JAR innych firm, w których zależy nam na wersjonowaniu, więc zostawiamy je tam, aby nowi programiści nie musieli ich pobierać . Przechodzimy do systemu zarządzanego, ale nadal mamy sprawdzone zależności zarządzane i niezarządzane. Oznacza to, że wszyscy programiści muszą tylko upewnić się, że w ich katalogach znajdują się dwa katalogi .classpath. Ale to lepsze niż konieczność naprawiania środowiska JRE za każdym razem, gdy pociągniesz i zmienianie ścieżki .classpath za każdym razem, gdy zatwierdzasz.

Eclipse robi jednak dla ciebie inne miłe rzeczy. Plik .project będzie zwykle taki sam we wszystkich instancjach, więc dołącz go. Ale najlepszą rzeczą w kontroli źródła dla zaćmienia są ustawienia Run Configurations. Na karcie „Wspólne” w oknie dialogowym Konfiguracje uruchamiania zapisz konfiguracje, aby były widoczne dla Twoich współpracowników na listach ulubionych funkcji Debuguj i Uruchom. Dla mnie do .launchkatalogu trafia kilka plików .settings, więc wszyscy możemy z nich korzystać.

Więc mówię: .settingskatalog przechodzi do kontroli źródła w celu uruchomienia konfiguracji (z wyjątkiem * .prefs)

.classpath pozostaje na zewnątrz

.project wchodzi.

Wpisałbym te pliki, aby ułatwić nowym użytkownikom start. W najlepszym przypadku użytkownik powinien sprawdzić projekt i powinien móc go uruchomić bez dodatkowej wiedzy. Dla tych plików zasady są takie same jak dla innych plików w projekcie: obchodź się z nimi ostrożnie. Nie należy umieszczać bezwzględnych ścieżek w kodzie źródłowym, podobnie jak w plikach konfiguracyjnych.

Jeśli pliki są wpisane w taki sposób, że projekt działa od zera, nie powinno być dużych sił do ich zmiany.

Zalecałbym sprawdzenie plików w subversion, JEŻELI nie zawierają one ścieżek bezwzględnych i innych danych, które wiązałyby je bezpośrednio ze środowiskiem jednego programisty.

Jeśli pliki zawierają ścieżki bezwzględne i tym podobne, lepszym wyborem byłby plik README.

Tak, zdecydowanie sprawdź je, ale upewnij się, że udokumentujesz wszelkie zależności ścieżek i unikaj ścieżek bezwzględnych, jeśli to możliwe.

Jeśli ich nie zarejestrujesz, każdy, kto będzie sprawdzał projekt, będzie musiał odtworzyć wszystkie te ustawienia, co jest denerwujące i potencjalnie podatne na błędy.

Niektóre złożone konfiguracje mogą być lepiej obsługiwane przez skrypt generujący te pliki, ale zwykle lepiej jest je po prostu zaewidencjonować.