Zdalne repozytorium Maven + Podpisy GPG

Po krótce opowiem jak zrobić własne repozytorium Mavena na w zasadzie dowolnym hostingu.

Mavena myślę, że przedstawiać nie trzeba, każdy kto miał do czynienia z JVM powinien znać ten system. Nawet jeśli używasz gradle, to oczywiście paczki dalej są ciągnięte z repozytoriów Mavena. Istnieje kilka lokalizacji, które kryją się pod tym hasłem.

  1.  Repozytorium użytkownika, w katalogu domowym pod ~/.m2/repository. Pierwsze w kolejności przeszukiwania, tutaj są pobierane paczki, zanim zostaną użyte. Raz pobrana paczka jest dalej używana z tego miejsca.
  2. Repozytorium centralne (Maven Central Repository), w którym znajdują się w większości stabilne wersje oprogramowania, do użytku ogólnego.
  3. Repozytoria lokalne, które zapewniają dostęp do paczek nieobecnych w repozytorium centalnym.

Mam zamiar skupić się na tym ostatnim punkcie. O ile finalną wersję warto wstawić do repozytorium centralnego, mordując się nieco z procedurami (np. przez OSSRH), to w przypadku prywatnego użytku nie ma to sensu.

Repozytorium może być osiągalne przez spory zbiór protokołów, File, HTTP, FTP, SSH itd. http://maven.apache.org/wagon/wagon-providers/index.html

Repozytorium w systemie plików

Podstawowym przykładem jest wykorzystanie repozytorium w lokalnym folderze, do spakowania binarnych bibliotek razem z projektem.

Pozwala to na użycie paczek spoza Mavena, które w lokalnym repozytorium będą dostępne dla projektu. Wersja z id „project2” przydaje się dla projektu modułowego, dla którego ${basedir} w modułach jest „zwykle” poziom niżej względem rodzica (głównego pom.xml). Kto tworzy bardziej pokrętne struktury projektu, powinien sam sobie poradzić z dodaniem tego w inny sposób.

Nie możemy klasycznie wrzucić luzem jar do /lib, bo to działać nie będzie. Repozytorium musi mieć zachowaną strukturę. By dodać paczkę do repozytorium, należy użyć polecenia

Każda paczka zainstalowana w ten sposób, będzie osiągalna w projekcie. Oczywiście, to nie jest dobre podejście, jeśli używamy systemu kontroli wersji, w którym, z zasady, żadnych obiektów binarnych się nie przechowuje.

Zdalne repozytorium

Innym podejściem jest wrzucanie współdzielonych z innymi osobami paczek w jakiejś wspólnej lokalizacji, na przykład na serwerze, poprzez HTTP. Wystarczy najbardziej prymitywny hosting. Możemy to zautomatyzować proces wrzucania plików na serwer poprzez deploy. Wykorzystam do tego połączenie FTP.

Extension jest potrzebne do obsługi FTP przez deploy-plugin. Potrzebujemy też jakiś danych uwierzytelniających dla połączenia FTP. Dla przykładu konfiguracja poprzez ustawienia użytkownika w  ~/.m2/settings.xml

Kluczowe jest id, które podajemy w pom.xml projektu.

W projekcie wykonujemy

co powinno wgrać pliki na serwer.

Oczywiście, do pełni szczęścia brakuje tego, by pliki wgrane przez FTP byłby osiągalne przez HTTP. Wtedy wystarczy użyć

Na innej maszynie Maven użyje tego repozytorium i pobierze niezbędne paczki.

Podpis Cyfrowy.

No, a co jakbyśmy jednak chcieli wgrać paczkę do repozytorium centralnego? Jednym z wymogów jest podpisanie jej przy użyciu swojego klucza.

Jeśli jeszcze nie korzystałeś z GPG, musisz wygenerować parę kluczy.

Potrzebne będzie hasło zabezpieczające klucz. Potem można wgrać publiczną część klucza na serwer

Skoro jest już klucz, to można użyć pluginu podpisującego

Kluczowy jest parametr useAgent, który odpali agenta GPG, który poda mu hasło do klucza. W jaki sposób, to już zależy od konfiguracji GPG, zwykle prompt.

Ponieważ faza verify jest przed install (Maven Lifecycle), składanie podpisu może być upierdliwe. Dobrym pomysłem jest wrzucenie podpisu i deploy w oddzielny profil. No, ale o profilach to może kiedy indziej.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *