🥇Zkušenost s používáním flatten-maven-plugin pro zjednodušení verzování v maven projektech

O nás

Ve 1C vyvíjíme nejen platformu 1C: Podnikání na C++ a JavaScript, ale také aplikace v Javě – konkrétně nové vývojové prostředí Nástroje pro podnikový vývoj na bázi Eclipse a server hluboce integrovaný s platformou messenger – Systémy interakce.

Úvod

Jako systém sestavování Java aplikací nejčastěji používáme maven a v tomto malém článku bychom chtěli hovořit o jednom z problémů, kterému jsme čelili podczas organizace vývoje, a o přístupu, který nám tento problém pomohl překonat.

Základní východiska a pracovní proces

Vzhledem ke specifikám vývoje v našich maven projektech používáme dostatek modulů, závislostí a podprojektů. Počet pom souborů v jednom stromu může být desítky nebo dokonce stovky.

Na první pohled: nic hrozného, jednou vytvoříme a zapomeneme. Pokud je třeba něco změnit nebo přidat ve všech souborech najednou, existuje množství pohodlných nástrojů v editorech a IDE. A jaká je nejběžnější pravidelná změna pom.xml? Předpokládáme, že změna verzí projektu a závislostí. Možná, že s tím někdo bude chtít polemizovat, ale u nás to takto funguje. Důvod je v tom, že vedle jádra zároveň vyvíjíme mnoho vlastních knihoven a pro stálou reprodukovatelnost výsledků sestavení a testování se nám použití snapshotů nezdá pohodlným přístupem. Z tohoto důvodu musíme zvyšovat číslo verze v projektech při každém sestavení.

Také u vývojáře se občas objevuje potřeba sestavit svou větev nějaké knihovny a ověřit její funkčnost vůči všem závislostem, pro což v nich všem musíme ručně měnit verzi.

Původní řešení

S tak častými a mnoha změnami verzí chceme proces v rámci CI zjednodušit a automatizovat. Sem přichází na pomoc pohodlný, veřejně známý plugin versions-maven-plugin — připojíme ho a spustíme

mvn -N versions:set -DnewVersion=2.0.1

a Maven to vše udělat jak má: proběhne hierarchií shora dolů, všechny verze nahradí — krása! Teď zbývá zvednout pull-request, kolegové změny zkontrolují, a můžeme rychle naskočit do trunku. Rychle? Jakoby ne. Pár set pom.xml na revizi, a to nepočítaje kód. Navíc se nikdo nezaručuje před merge konflikty při tak velkém počtu změněných souborů. Je třeba poznamenat, že během CI se změny verzí automaticky dějí spolu se změnou funkcionality, a ne nějak zvlášť.

Nové možnosti

Na chvíli jsme se uklidnili a smířili se, tak jsme žili, dokud páni z Maven Apache Project nezahrnuli do maven, počínaje verzí 3.5.0-beta-1, podporu tzv. "náhradníků" verzí (placeholders). Podstatou těchto náhradníků je to, že místo konkrétního uvedení verze projektu se používají proměnné pom.xml ${revision} ${sha1}, ${changelist} a . Hodnoty těchto vlastností se definují buď v elementu <properties>, nebo je lze definovat prostřednictvím systémové vlastnostimvn -Drevision=2.0.0 clean package

Hodnoty systémových vlastností mají přednost před hodnotami definovanými v <

>.>, nebo je lze definovat prostřednictvím systémové vlastnostiRodič

<project>
<modelVersion>4.0.0<\/modelVersion>
  <parent>
  <groupId>org.apache<\/groupId>
    <artifactId>apache<\/artifactId>
    <version>18<\/version>
    <\/parent>
  <groupId>org.apache.maven.ci<\/groupId>
  <artifactId>ci-parent<\/artifactId>
  <name>First CI Friendly<\/name>
  <version>
  ${revision}${sha1}${changelist}<\/version><properties>
  …
  <revision>
    <\/revision>1.3.1<changelist>
    -SNAPSHOT<\/changelist><sha1\/>
    <\/properties>
  <\/project>
Potomok

<artifactId>ci-child<\/artifactId>
<modelVersion>4.0.0<\/modelVersion>
  <parent>
  <groupId>org.apache<\/groupId>
    <artifactId>ci-parent<\/artifactId>
    <name>First CI Friendly<\/name>
    ${revision}${sha1}${changelist}<\/version><properties>
  <groupId>org.apache.maven.ci<\/groupId>
  <artifactId>ci-parent<\/artifactId>
  Pokud chceš sestavit verzi 2.0.0-SNAPSHOT, stačí použít
   …
Potomok

Pokud chceš udělat release, jednoduše resetujeme SNAPSHOT

Hodnoty systémových vlastností mají přednost před hodnotami definovanými v <

mvn -Dchangelist= clean package

*Příklady výše jsou převzaty z

článku na stránkách Maven Apache Project Drsná realita

Všechno je skvělé a v pořádku, je čas zažít pocit uspokojení, ale ne. Ukazuje se, že pro install a deploy tento způsob nevyhovuje, protože v popisech publikovaných v repozitáři artefaktů se nahradí

její hodnotou a maven pak nepochopí, o čem vůbec mluvíme. ${sha1} <version>${revision}<\/version>

<groupId>org.apache<\/groupId>
    <artifactId>apache<\/artifactId>
    <version>18<\/version>
    Světlo na konci tunelu
<groupId>org.apache.maven.ci<\/groupId>

Musíme hledat řešení problému. Situaci by mohl zachránit

flatten-maven-plugin flatten-maven-pluginTento plugin umožňuje všechny proměnné v pom, ale zároveň odstraňuje množství dalších informací, které jsou potřeba pouze při sestavení a nejsou potřebné při importu publikovaných artefaktů do jiných projektů. Plugin také "vyrovnává" všechny závislosti parent-child, a výsledkem jsou ploché pom, které zahrnují vše, co je potřeba. Nepohodlí spočívalo v tom, že odstraňoval "příliš mnoho zbytečného", což nás vůbec nevyhovovalo. Po prozkoumání informací o vývoji tohoto pluginu se ukázalo, že nejsme sami ve vesmíru, a již v srpnu 2018 byl na GitHubu v repozitáři pluginu vytvořen pull-request s přáním udělat možnost určovat samostatně, jak je potřeba "porovnat" pom.xml. Vývojáři naslouchali hlasům potřebných, a už v prosinci s vydáním nové verze 1.1.0 se ve flatten-maven-plugin objevil nový režim resolveCiFriendliesOnly, který nastal jako nikdy dřív – ponechává pom.xml tak, jak je, kromě prvku ${revision}${sha1}${changelist} a umožňuje ${sha1}, ${changelist} a . Hodnoty těchto vlastností se definují buď v elementu <.

Přidáváme plugin do projektu

<plugins>
  <plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>flatten-maven-plugin</artifactId>
    <version>1.1.0</version>
    <configuration>
      <updatePomFile>true</updatePomFile>
      <flattenMode>resolveCiFriendliesOnly</flattenMode>
    </configuration>
    <executions>
      <execution>
        <id>flatten</id>
        <phase>process-resources</phase>
        <goals>
          <goal>flatten</goal>
        </goals>
      </execution>
      <execution>
        <id>flatten.clean</id>
        <phase>clean</phase>
        <goals>
          <goal>clean</goal>
        </goals>
      </execution>
    </executions>
  </plugin>
</plugins>

Hotovo!

Šťastný konec

Od nynějška potřebujeme, abychom změnili verzi celého projektu a dali vědět všem závislostem, pouze upravit prvek <revision> v jediném kořenovém pom.xml. Na revizi přichází ne stovka-dvě těchto souborů se stejnou změnou, ale pouze jeden. Také odpadá potřeba používat versions-maven-plugin.

Zdroj: habr.com