Tworzenie niezależnych modułów z wieloma modułami i wydawanie pojedynczych modułów?

Question

Obecnie pracuję nad optymalizacją maven kompilacji wielomodułowego projektu maven. Projekt składa się z około 90 modułów Maven. W ogóle są jakieś libs przekrojowe tworzące rdzeń i wtedy istnieje około 15 „moduły aplikacji” składające się na całą aplikację (który jest następnie wdrożony jak w wojnie)

Teraz w ogóle cały projekt ma główna wersja "2.5", więc po wydaniu nowej głównej wersji wszystkie "moduły aplikacji" mają tę samą wersję "2.5.0". Jak na razie dobrze.

Jeśli moduł ma błąd, który należy naprawić lub wymaga naprawy, powinna zostać wydana nowa wersja tego "modułu aplikacji". Na przykład moduł A ma naprawiony błąd, a następnie A.jar powinien być w wersji "2.5.1", podczas gdy reszta powinna nadal być "2.5.0".

nadrzędny (2.5.0-SNAPSHOT - Moduł A (2.5.1-tło) - moduł B (2.5.0-tło) - moduł C (2.5.2-tło) - War (2.5. 3-SNAPSHOT) < - 3 na końcu, ponieważ C miał 2 ponowne wydania i jedną i został wydany po każdym wydaniu modułu dla uproszczenia

Postanowiliśmy zarządzać wersjami artefaktów w master pom, więc nie po zwolnieniu jednego modułu trzeba zaktualizować wersje zależności każdego artefaktu:

Tak więc, gdy tylko zaktualizowany "moduł aplikacji" jest gotowy, używamy klucza zwolnij plugin, aby wykonać wydanie tego modułu (Wydajemy jeden moduł, a nie cały projekt). Powiedzmy, że zwalniamy moduł A w wersji 2.5.4, w wyniku czego A.jar jest wdrażany jako wersja 2.5.4 i kończy się aktualizacją kodu modułu do wersji 2.5.5-SNAPSHOT.

Po wykonaniu tej czynności należy zaktualizować wersję w master pom, aby wszystkie moduły nadal odwoływały się do odpowiedniej wersji.

Dzięki sekcji dependencyManagement z pom nadrzędnego, jeśli zbudować moduł wojnie, to automatycznie pobierze nową wersję modułu A.

Teraz najtrudniejsze: Jak tylko wszystkie moduły są zwolnione, nowa wersja aplikacji internetowej powinna zostać wydana. Powinno to zawierać wszystkie niezmienione moduły, a także te, które zostały właśnie wydane. Obecnie walczę, jak to zrobić. Jeśli będę zależał od macierzystej wersji poms, wydanie będzie zawierało wersje SNAPSHOT (wszystkie przyrosty jednej wersji zbyt wysokie), których ja i wtyczka wydania nie akceptujemy.

Jakie byłoby najlepsze rozwiązanie tego dylematu?

Miałem jeden pomysł, aby wyeksportować zarządzanie zależnościami do osobnej pompy pom, która jest następnie importowana do modułu zarządzania zależnością master poms za pomocą zakresu "import".

Czy ten rodzaj szenario jest głupim pomysłem? Czy istnieją alternatywy dla opracowania i utrzymania dużej wielomodułowej aplikacji takiej jak ta? Po prostu posiadanie wszystkich wersji zsynchronizowanych i używanie wtyczki wydania w całym projekcie nie jest opcją, ponieważ aplikacja jest duża, a aplikacje klienckie muszą ładować zaktualizowane wersje modułów. Niektórzy z naszych klientów mają bardzo powolne połączenia, więc za każdym razem rozwijanie wszystkich modułów czyni ich naprawdę nieszczęśliwymi.

Pomoc mile widziana,

Chris

Answer 1

Więc wymyśliłem rozwiązanie dla mojego problemu. Jest to mieszanka małej łatki plug-in-plug-plug i wtyczki Jenkinsa, która obsługuje bardzo wymagającą konfigurację linii poleceń.

Opis procesu wydania: https://dev.c-ware.de/confluence/display/PUBLIC/Releasing+modules+of+a+multi-module+project+with+independent+version+numbers

Opis Jenkins Plugin: https://dev.c-ware.de/confluence/display/PUBLIC/Developing+a+Jenkins+Plugin+for+the+Maven+Release+Plugin

Kod Plugin: https://github.com/chrisdutz/jenkins-release-plugin

Answer 2

Przede wszystkim ważne jest, aby uświadomić sobie, że numery wersji, a ważne dla zarządzania zależność, są całkowicie arbitralne. Przynajmniej forma numeru wersji jest dowolna (tak, jestem świadomy the syntax for Maven version ranges, o której nigdy nie słyszałem, aby ktokolwiek korzystał). Niektóre projekty OSS całkowicie unikają "tradycyjnych" numerów wersji i używają tylko wersji lub dat repozytorium SVN dla wersji.

Jedną z opcji jest brak wersji "projektowej", a raczej umożliwienie każdemu z komponentów posiadania różnych numerów wersji. Uważam, że jest to całkowicie dopuszczalne rozwiązanie.

Kolejnym rozwiązaniem jest wydanie za pomocą zależności migawki. Nie powinno się tego "robić", ale nic nie powstrzymuje cię przed trudnym kodowaniem wersji snapshot (która jest niewiarygodnie dokładna i ma znacznik czasu). Zresztą nic poza widmem niepowtarzalnych budowli.

Jeśli wszystkie komponenty mają ten sam numer wersji, sugeruję dodanie numeru kompilacji do mniejszego komponentu wersji projektu.

W tym podejściu wykorzystuje się Maven Build Number plugin do rozróżniania stopniowych wersji w ramach wersji opisanej w pytaniu: Can I set the project version with a buildnumber-maven-plugin?.

Uwaga: zrobiłbyś to tylko w profilu "ostatecznej wersji", który jest używany tylko przez twój serwer budujący (lub przez twojego inżyniera budującego).

Version Numbers plugin jest również twoim przyjacielem tutaj.

Ostateczna workflow uwolnienie byłoby coś jak poniżej:

1. start wersji 2.5.5-SNAPSHOT.
2. mvn versions:set -DnewVersion 2.5.5.
3. Zatwierdź i oznacz swoją wersję (lub utwórz oddział - niezależnie od strategii).
4. mvn deploy -Prelease który aktywuje twój "profil wydania", który dodaje numer kompilacji do artefaktu finalName.
5. mvn versions:set -DnewVersion 2.5.5-SNAPSHOT.
6. Zatwierdź swoją wersję "po wydaniu".

Przyrost do wersji 2.5.6, 2.6.0 itd., Gdy masz naprawdę "poważne" wydanie.

Powodzenia!

Answer 3

Ubiegłej nocy zdałem sobie sprawę, że kompilacja, o której napisałem w swoim pytaniu, miała inny poważny problem: moduły mają między sobą depa i te nie będą obsługiwane przez wtyczkę wydania. Te zależności SNAPSHOT spowodowałyby awarię wtyczki (co jest dobre).

Po prostu miałem inny pomysł, który mógłby rozwiązać moje problemy: Utworzyłem dwa artefakty z "maven pom" "versions-dev" i "versions-rel", które zawierają sekcję dependencyManagement, która definiuje wersje dev i rel. W moim master pom bym teraz utworzył dwa profile "development" (domyślnie aktywny) i "release", który należy aktywować ręcznie.Profile te zawierają sekcję dependencyManagement, a każda importuje zależność Zarządzanie obiektem artefaktu wersji pom za pomocą zakresu "import".

Teraz wydanie będzie musiało wykonać następujące kroki: - Zaktualizuj wersje-rel i wersje-dev do nowych wersji. - Commit - Tag - uruchomić uwalnianie: Wykonaj cel uwolnienia plugin

Jest jeszcze jedna rzecz, która może powodować problemy: Zakładając, że wszystkie moduły zostały zmodyfikowane, ale tylko jedna powinny być zawarte w nowym wydaniu wówczas takie podejście spowoduje również ponowne wdrożenie wszystkich modułów, nawet tych, których nie chcę zwolnić. Spowoduje to wdrożenie zmienionych wersji w tej samej wersji co wcześniej wydane wersje. Teraz mogłem tego uniknąć, nie zwalniając głównego projektu, a jedynie pojedyncze moduły. Jeśli jednak można wdrożyć tylko te wersje, które nie są już wdrożone, znacznie ułatwiłoby to proces wydawania.

Jakieś sugestie, zastrzeżenia, rzeczy, które wybaczam?

Chris