O nas
W 1C rozwijamy nie tylko platformę na и , ale także aplikacje Java - w szczególności nowe środowisko programistyczne oparty na Eclipse i serwerze komunikatorów głęboko zintegrowanym z platformą - .
Wejście
Najczęściej używamy mavena jako systemu kompilacji aplikacji Java i w tym krótkim artykule chcielibyśmy porozmawiać o jednym z problemów, z którymi musieliśmy się zmierzyć w procesie organizacji rozwoju oraz o podejściu, które pozwoliło nam to pokonać problem.
Warunki wstępne i przepływ pracy
Ze względu na specyfikę rozwoju w naszych projektach mavenowych wykorzystujemy całkiem sporo modułów, zależności i projektów potomnych. Liczba plików pom w jednym drzewie może wynosić dziesiątki, a nawet setki.
Wydawałoby się: nic wielkiego, raz to stworzyli i zapomnieli o tym. Jeśli chcesz zmienić lub dodać coś we wszystkich plikach na raz, w edytorach i IDE dostępnych jest wiele wygodnych narzędzi. Jaka jest najczęstsza regularna zmiana w pliku pom.xml? Wierzymy, że zmiany w wersjach projektu i zależnościach. Być może ktoś będzie chciał się z tym kłócić, ale u nas dokładnie tak jest. Powodem jest to, że wraz z jądrem rozwijamy jednocześnie wiele własnych bibliotek, a dla stałej powtarzalności wyników kompilacji i testów stosowanie migawek nie wydaje nam się wygodnym podejściem. Z tego powodu konieczne jest podnoszenie numeru wersji w projektach przy każdej kompilacji.
Ponadto od czasu do czasu programista musi zbudować własną gałąź biblioteki i sprawdzić jej funkcjonalność pod kątem wszystkich zależności, dla których musi ręcznie zmienić wersję wszystkich z nich.
Rozwiązanie początkowe
Przy tak częstych i wielokrotnych zmianach wersji chcę uprościć i zautomatyzować proces w ramach CI. Tutaj z pomocą przychodzi wygodna, dobrze znana wtyczka. wersje-maven-plugin - podłącz go i uruchom
mvn -N wersje: zestaw -DnewVersion=2.0.1
a Maven zrobi wszystko tak, jak powinien: przebiegnie hierarchię od góry do dołu, zastępując wszystkie wersje - piękność! Teraz pozostaje tylko zgłosić żądanie ściągnięcia, współpracownicy przejrzą zmiany i będziesz mógł szybko dołączyć do łącza trunkingowego. Szybko? Nieważne jak to jest. Kilkaset pom.xml do przeglądu i to nie jest liczenie kodu. Ponadto nikt nie jest bezpieczny przed konfliktami scalania przy tak dużej liczbie zmienionych plików. Należy tu zaznaczyć, że w procesie CI zmiany wersji następują automatycznie wraz ze zmianami funkcjonalności, a nie jakoś osobno.
Nowe funkcje
Na chwilę uspokoiliśmy się i po rezygnacji żyliśmy tak, aż do chłopaków Począwszy od wersji 3.5.0-beta-1, Maven nie zawierał obsługi tzw. „placeholderów”. Istota tych substytutów polega na tym pom.xml zamiast konkretnego wskazania wersji projektu stosuje się zmienne ${wersja}, ${sha1} и ${lista zmian}. Same wartości tych właściwości są ustawiane albo w elemencieniska zabudowa> lub można je zdefiniować poprzez właściwość systemową
mvn -Drevision=2.0.0 czysty pakiet
Wartości właściwości systemowych mają pierwszeństwo przed wartościami zdefiniowanymi wniska zabudowa>.
Rodzic
4.0.0
org.apache
Apache
18
org.apache.maven.ci
ci-rodzic
Pierwszy przyjazny dla CI
${wersja}${sha1}${lista zmian}
...
1.3.1
-MIGAWKA
Potomek
4.0.0
org.apache.maven.ci
ci-rodzic
${wersja}${sha1}${lista zmian}
org.apache.maven.ci
ci-dziecko
...
Jeśli chcesz zbudować wersję 2.0.0-SNAPSHOT, po prostu użyj
mvn -Drevision=2.0.0 czysty pakiet
Jeśli chcesz wydać wersję, po prostu zresetuj SNAPSHOT
mvn -Dchangelist= czysty pakiet
*Powyższe przykłady pochodzą z na stronie internetowej projektu Maven Apache
Brutalna rzeczywistość
Wszystko dobrze i zdrowo, czas poczuć satysfakcję, ale nie. Okazuje się, że ta metoda nie będzie działać w przypadku instalacji i wdrażania, ponieważ nie zostanie zastąpiona w opisach artefaktów publikowanych w repozytorium ${wersja} na jego znaczeniu, a Maven nie będzie już rozumiał, o co w tym wszystkim chodzi.
org.apache
Apache
${wersja}
Światło na końcu tunelu
Musimy poszukać rozwiązania problemu. Mógłby uratować sytuację . Ta wtyczka rozwiązuje wszystkie zmienne w pom, ale jednocześnie wycina wiele innych informacji, które są potrzebne tylko podczas montażu i nie są potrzebne podczas importowania opublikowanych artefaktów do innych projektów. Wtyczka „prostuje” także wszystkie zależności rodzic-dziecko, w wyniku czego otrzymujesz płaski pom, który zawiera wszystko, czego potrzebujesz. Niedogodnością było to, że wycinało za dużo „dodatków”, co zupełnie nam nie odpowiadało. Po przestudiowaniu informacji na temat rozwoju tej wtyczki okazało się, że nie jesteśmy jedyni we wszechświecie i już w sierpniu 2018 roku na Githubie w repozytorium wtyczek utworzono pull-request z chęcią umożliwienia aby samodzielnie ustalić, jak „zepsuć” pom.xml. Twórcy wsłuchali się w głosy cierpiących i już w grudniu wraz z wydaniem nowej wersji 1.1.0 we wtyczce flatten-maven pojawił się nowy tryb, requireCiFriendliesOnly, który był bardziej odpowiedni niż kiedykolwiek - pozostawia pom.xml bez zmian, z wyjątkiem elementu i pozwala ${wersja}, ${sha1} и ${lista zmian}.
Dodanie wtyczki do projektu
org.codehaus.mojo
flatten-maven-plugin
1.1.0
PRAWDA
rozwiązaćTylkoCiFriendlies
spłaszczyć
zasoby procesowe
spłaszczyć
spłaszczyć. oczyścić
czysty
czysty
Gotowe!
szczęśliwe zakończenie
Od tej chwili, aby zmienić wersję całego projektu i dać znać o tym wszystkim zależnościom, wystarczy, że dokonamy edycji elementurewizja> tylko w katalogu głównym pom.xml. Do recenzji trafia nie sto czy dwa takie pliki z tą samą zmianą, ale jeden. Cóż, nie ma potrzeby używać wersje-maven-plugin.
Źródło: www.habr.com
