Pliki projektu Eclipse a kontrola wersji

Czy pliki projektu Eclipse powinny być umieszczane w systemie kontroli wersji?

Zanim odpowiemy sobie na to pytanie – krótko – czym są takie pliki? Pliki projektu środowiska Eclipse zawierają informacje związane z konfiguracją samego środowiska oraz ustawieniami projektu. Tworzone są wraz z projektem, zapisywane w jego folderze. Są to m.in. .project oraz .classpath.

Istnieją różne podejścia do przechowywania tych plików w repozytorium. Jedni twierdzą, że nie powinny być w ogóle wersjonowane – każdy bowiem posiada własną konfigurację środowiska. Inni – przeciwnie – że zawsze powinny być w nim umieszczane.

Warto pamiętać, że w plikach projektu znajdują są takie informacje, jak kodowanie znaków, stosowana wersja kompilatora oraz zależności. Wypadałoby więc, żeby wszyscy członkowie zespołu posiadali te same ustawienia i mieli dane o użytych zewnętrznych bibliotekach. Jeżeli nie jest stosowany Maven lub inne narzędzie automatyzujące proces budowy projektu, a więc i znajdowania zależności, plik .classpath jest bezpośrednim źródłem informacji o nich. Bez niego konieczne jest analizowanie kodu w celu stwierdzenia dlaczego dana klasa nie jest dostępna – jakiej brakuje biblioteki?

Z drugiej strony plik .classpath często zawiera te informacje w postaci ścieżek bezwzględnych, co jest głównym argumentem przeciwko przechowaniu go w systemie kontroli wersji.

Można więc stwierdzić, że pliki projektu powinny być wersjonowane pod warunkiem, że nie zawierają ścieżek bezwzględnych.

Jak więc umieścić w nim informację o zależnościach unikając użycia ścieżek bezwzględnych? Eclipse daje możliwość zastosowania do tego celu zmiennych – Classpath Variables.

Zarządzanie zmiennymi classpath dostępne jest m.in. z poziomu preferencji (Kepler):

menu Window → Preferences → Java → Build Path → Classpath Variables

Istnieje możliwość tworzenia zarówno zmiennych zawierających ścieżki plików jak i folderów. Druga opcja jest szczególnie przydatna w przypadku wielu bibliotek dołączanych do projektu znajdujących się w tym samym katalogu bądź strukturze katalogów. Podstawą ścieżek do nich może być więc jedna zmienna.

Kiedy zmienne zostaną już zdefiniowane, mogą zostać wykorzystane w Java Build Path projektu:

Preferencje projektu → Java Build Path → zakładka Libraries → przycisk Add Variable

Zaznaczenie zmiennej wskazującej na folder aktywuje przycisk Extend. Jego wciśnięcie pozwala na wybór pliku wewnątrz tego folderu.

Zapis tak skonfigurowanego Build Path projektu spowoduje wygenerowanie w pliku .classpath wpisów bez ścieżek bezwzględnych – z wykorzystaniem zmiennych classpath. Przykładowe wpisy, odpowiednio dla plików i folerów:

<classpathentry kind="var" path="ZMIENNA_FOLDERU/biblioteka.jar"/>
<classpathentry kind="var" path="ZMIENNA_PLIKU"/>

Warto pamiętać o nazewnictwie. Ważne jest, aby zmienne jasno i jednoznacznie określały to, co się pod nimi kryje tak, aby programista pobierający dane z repozytorium po raz pierwszy mógł szybko zidentyfikować plik / folder i ew. utworzyć sobie brakującą dla niego zmienną.

Stosując powyżej opisane rozwiązanie

• Przechowujemy w repozytorium dane dotyczące zależności
• Unikamy konfliktu lokalizacji zależności w różnych środowiskach programistycznych
• Nikt nie umieści w repozytorium lokalnych ścieżek
• Programista nie musi po ponownym pobraniu zawartości repozytorium (nie aktualizacji – np. w wyniku usunięcia lokalnej kopii repozytorium / części repozytorium git/mercurial) zmieniać ścieżek do bibliotek w Build Path
• Wystarczy jednorazowa czynność utworzenia zmiennych classpath – np. do folderu modułów lokalnego serwera