Maven. Brak update'u artefaktu?!

Tak sobie ostatnio pomyśleliśmy, że niektóre materiały wrzucane na naszą grupę na facebooku można jeszcze nieco rozwinąć i stworzyć z tego fajny artykuł dla większej grupy odbiorców. Właśnie w taki sposób powstał ten tekst.

Na grupie zajmowaliśmy się ostatnio problemem, którego wystąpienie potrafi doprowadzić do szału, szczególnie początkujących użytkowników Mavena (choć nie tylko). Problem ten dotyczy braku aktualizacji artefaktu w lokalnym repozytorium, mimo że właśnie zbudowaliśmy jego nową wersję i wykonaliśmy deploya na zdalne repozytorium, a inny projekt ma ten artefakt podpięty jako zależność i tę aktualizację ma zobaczyć. Brzmi skomplikowanie? Możliwe. Rozbijmy to zatem na kolejne kroki, występujące w ramach konkretnego scenariusza.

Tworzenie projektów i ustalenie zależności

• Tworzymy nowy projekt, np. Genres, który przechowuje gatunki filmowe. Gatunki filmowe nie zmieniają się za często, dlatego postanawiamy wyodrębnić tę część do osobnego projektu i taki projekt zbudować Mavenem do postaci artefaktu.
• Wgrywamy ten artefakt (wykonujemy deploy) do zdalnego repozytorium Mavena.
• Tworzymy projekt MovieStore (baza filmów), który ma podpięty artefakt Genres.
• Budujemy Mavenem projekt MovieStore.
  • Pobieranie artefaktu Genres ze zdalnego repozytorium jest wyzwalane przez projekt MovieStore, czyli ten zawierający dependency artefaktu.
• Projekt MovieStore może korzystać z klas artefaktu Genres. W ten sposób uzyskaliśmy na przykład dostęp do metody zwracającej listę gatunków filmowych.

Do tej pory wszystko gra. Zabawa zaczyna się w momencie, gdy chcemy zaktualizować artefakt podpięty do innego projektu jako zależność (czyli do projektu MovieStore).

Aktualizacja artefaktu

• Dodajemy klasę do Genres (na przykład konwerter językowy nazw gatunków, bo okazuje sie, że nasz projekt ma być udostępniony w kilku krajach) i przebudowujemy go Mavenem.
• Wgrywamy nową wersję artefaktu do zdalnego repozytorium.
• W projekcie MovieStore chcemy wykorzystać nową klasę z artefaktu Mavena.
• Przebudowujemy więc projekt MovieStore.

I teraz pojawia się pytanie. Czy w ostatnim kroku nowa wersja artefaktu Genres zawsze zostanie ściągnięta ze zdalnego repozytorium i tym samym będziemy mogli użyć skonwertowanych nazw gatunków w projekcie MovieStore? Odpowiedź brzmi — Nie zawsze! Appa Notka. Pobieranie zostanie wyzwolone tylko w przypadku wersji SNAPSHOT, np. 1.0.0-SNAPSHOT i tylko wtedy, gdy zdalne repozytorium zawiera nowszą wersję. Bazując na naszym przykładzie, w przypadku gdy mamy gotową wersję releasową projektu Genres, np. 1.0.0 i do takiej wersji artefaktu dodaliśmy klasę i tą zdeployowaliśmy do zdalnego repozytorium, wówczas nic nie zostanie pobrane przez projekt MovieStore. Można się na tym złapać, jeśli na "dzień dobry" w projekcie ustawimy sobie wersję bez -SNAPSHOT, bo "tak wygląda czytelniej". Może też być tak, że zaczynamy pracę nad zapomnianym projektem i ma on wersję na przykład 7.0.0. Zmieniamy ją, budujemy artefakt i patrzymy, a nasz projekt główny (MovieStore) nie zauważył żadnej zmiany.

W takiej sytuacji po dłuższym śledztwie dochodzimy do tego, że w naszym lokalnym repozytorium nadal znajduje się wersja z datą z dalekiej przeszłości. Maven nie ściągnął nowej wersji artefaktu. Jak to możliwe? Chyba jest jakiś błąd w Mavenie! Zepsuł się.

No właśnie, ale czy w ogóle możemy mówić o nowej wersji, skoro wcześniej w repozytorium istniała wersja 7.0.0, a obecna wersja to nadal 7.0.0? No nie. Jeśli już chcemy aktualizować kod wersji releasowej, to należy zaktualizować numer, na przykład na 7.0.1, a następnie zmienić także numer wersji w projekcie głównym (czyli numer wersji dependency) i ten projekt przebudować.

Podsumowanie

Pojawia się jednak pytanie. Czemu to tak nie działa bez zmiany wersji? Przecież ostatnio mi działało! No właśnie, mogło działać, jeśli Twoja wersja miała dodany postfix -SNAPSHOT. Wtedy bez podmieniania numerów wersji można zaktualizować artefakt, wgrać go na zdalne repozytorium, a build projektu głównego wyzwoli pobranie artefaktu do lokalnego repozytorium (mimo że nie było zmiany wersji, ważne że jest nowszy znacznik czasu zapisany przy artefakcie w zdalnym repozytorium). Appa Notka. Na domyślne zachowanie Mavena możemy jeszcze wpływać poprzez zastosowanie updatePolicy w settings.xml, ale to już temat na inny artykuł. Pomijając samą zasadę, to oczywiście nie jest dobrą praktyką wypuszczanie od razu wersji release z pominięciem snapshot-a, ale czasem zdarza się, że deweloper tak zrobi. Bo na przykład dobrze zna kod artefaktu, zmienia drobiazg i nie potrzebuje testów. Czasem jest też tak, że programista robi tak na przykład dlatego, że się spieszy. Cóż, zawsze warto spieszyć się powoli :) Zapraszamy Was do dołączenia do naszej grupy na facebooku (poniżej)! Znajdziecie tam sporo materiałów ze świata Javy, Spring-a i Hibernate'a niepublikowanych w portalu. Co więcej, czasem trafi się również smakowity kąsek w postaci posta o mikroserwisach albo o chmurze IT. To tam regularnie wrzucamy newsy i ciekawostki, a także smart rozwiązania. Na grupie jeszcze szybciej dowiesz się, co w trawie piszczy i co już czai się za rogiem (psst... Spring Boot 3 już niedługo :) ) Autor: Jarek Klimas, Patrycja Klimas
Data: 31 stycznia 2022
Labele:Backend, Poziom średniozaawansowany, Java, Maven Linki: Maven [doc] - Settings.xml