O nás
V 1C vyvíjíme nejen platformu
Vstup
Nejčastěji používáme maven jako sestavovací systém pro Java aplikace a v tomto krátkém článku bychom chtěli hovořit o jednom z problémů, kterým jsme museli čelit v procesu organizace vývoje, a o přístupu, který nám umožnil tento problém překonat. problém.
Předpoklady a pracovní postup
Vzhledem ke specifikům vývoje v našich maven projektech používáme poměrně hodně modulů, závislostí a dětských projektů. Počet souborů pom v jednom stromu může být v desítkách nebo dokonce stovkách.
Zdálo by se: žádný velký problém, jednou to vytvořili a zapomněli na to. Pokud potřebujete změnit nebo přidat něco ve všech souborech najednou, existuje spousta pohodlných nástrojů v editorech a IDE. Jaká je nejčastější pravidelná změna na pom.xml? Věříme, že změny ve verzích a závislostech projektu. Možná s tím někdo bude chtít polemizovat, ale přesně taková je situace u nás. Důvod spočívá ve skutečnosti, že spolu s jádrem současně vyvíjíme mnoho vlastních knihoven a pro neustálou reprodukovatelnost výsledků sestavení a testování se nám použití snapshotů nezdá jako vhodný přístup. Z tohoto důvodu je nutné zvýšit číslo verze v projektech s každým sestavením.
Vývojář si také čas od času potřebuje postavit vlastní větev knihovny a zkontrolovat její funkčnost vůči všem závislostem, u všech musí ručně změnit verzi.
Prvotní řešení
S tak častými a vícenásobnými změnami verzí chci zjednodušit a zautomatizovat proces v rámci CI. Zde přichází na pomoc pohodlný, dobře známý plugin. verze-maven-plugin - připojte jej a spusťte
mvn -N verze:set -DnewVersion=2.0.1
a Maven udělá vše, jak má: bude procházet hierarchií odshora dolů a nahradí všechny verze – krása! Teď už zbývá jen vznést žádost o stažení, kolegové zkontrolují změny a vy se můžete rychle připojit k kmenu. Rychle? Bez ohledu na to, jak to je. Pár stovek pom.xml ke kontrole, a to nepočítá kód. Navíc nikdo není v bezpečí před konflikty sloučení s tak velkým počtem změněných souborů. Zde je třeba poznamenat, že v procesu CI dochází ke změnám verze automaticky spolu se změnami funkčnosti a ne nějak odděleně.
Nové funkce
Na chvíli jsme se uklidnili a rezignovaně jsme tak žili až do chlapů z
mvn -Drevision=2.0.0 čistý balíček
Hodnoty systémových vlastností mají přednost před hodnotami definovanými vvlastnosti>.
Rodič
4.0.0
org.apache
apache
18
org.apache.maven.ci
ci-rodič
První CI Friendly
${revision}${sha1}${changelist}
...
1.3.1
-MOMENTKA
Potomek
4.0.0
org.apache.maven.ci
ci-rodič
${revision}${sha1}${changelist}
org.apache.maven.ci
ci-dítě
...
Pokud chcete sestavit verzi 2.0.0-SNAPSHOT, pak stačí použít
mvn -Drevision=2.0.0 čistý balíček
Pokud chcete provést vydání, stačí resetovat SNAPSHOT
mvn -Dchangelist= čistý balíček
*Výše uvedené příklady jsou převzaty z
Tvrdá realita
Všechno je dobré a zdravé, je čas cítit pocit zadostiučinění, ale ne. Ukazuje se, že tato metoda nebude fungovat pro instalaci a nasazení, protože nebude nahrazena v popisech artefaktů publikovaných v úložišti ${revision} na jeho významu a maven už nepochopí, o co jde.
org.apache
apache
${revision}
Světlo na konci tunelu
Musíme hledat řešení problému. Mohl zachránit situaci
Přidání pluginu do projektu
org.codehaus.mojo
flatten-maven-plugin
1.1.0
skutečný
resolveCiFriendliesOnly
zploštit
proces-zdroje
zploštit
zploštit.čistý
čistý
čistý
Hotovo!
Šťastný konec
Od této chvíle, abychom mohli změnit verzi celého projektu a dát o ní vědět všem závislostem, stačí upravit prvekrevize> pouze v kořeni pom.xml. Na recenzi nedorazí sto nebo dva těchto souborů se stejnou změnou, ale jeden. No, není potřeba používat verze-maven-plugin.
Zdroj: www.habr.com