🥇A flatten-maven-plugin használatának tapasztalata a Maven projektek verziókezelésének egyszerűsítésére

Rólunk

A 1C-nél nemcsak a platformot fejlesztjük 1C: Vállalat Gyorsan emlékezzünk vissza, hogyan működik a moduláris aritmetika. Az óra már egy ismert koncepció. Az órák használata C++ és JavaScript, hanem Java-alapú alkalmazásokat is - különösen egy új fejlesztői környezetet Enterprise Development Tools az Eclipse alapjain, és a szerver szorosan integrálva van a messenger platformmal - Interakciós rendszerek.

Bevezetés

Java-alkalmazások build rendszerének kidolgozásához leggyakrabban a maven-t használjuk, és ebben a rövid cikkben szeretnénk egy problémáról beszélni, amellyel szembesültünk a fejlesztés megszervezésének folyamatában, és egy megközelítésről, amely segített ezt a problémát megoldani.

Előfeltételek és munkafolyamat

A maven-projektjeink fejlesztésének sajátosságai miatt viszonylag sok modult, függőséget és almunkát használunk. Az egy fájlfában található pom-fájlok száma akár tucatnyi vagy akár több száz is lehet.

Azt hihetnénk, hogy: semmi különös, egyszer létrehoztuk és elfelejtettük. Ha bármit meg kell változtatnunk vagy hozzá kell adnunk az összes fájlhoz egyszerre, számos kényelmes eszköz áll rendelkezésre a szerkesztőkben és IDE-kben. De mi a leggyakoribb rendszeres változtatás a pom.xml fájlban? Úgy gondoljuk, hogy a projekt és a függőségek verziójának megváltoztatása. Lehet, hogy valaki szeretne ezzel vitatkozni, de nálunk a helyzet pontosan így van. Az ok az, hogy a mag mellett párhuzamosan sok saját könyvtárat is fejlesztünk, és a build és tesztelési eredmények folyamatos reprodukálhatósága érdekében a snapshotok használata számunkra nem tűnik kényelmes megoldásnak. Ezért minden buildkor emelni kell a verziószámot a projektekben.

A fejlesztőnek időnként szüksége van arra is, hogy összegyűjtse egy könyvtár szálát, és ellenőrizze a működését az összes függőséggel, ami miatt mindegyiken manuálisan kell megváltoztatni a verziót.

Kezdeti megoldás

Ilyen gyakori és sokszoros verzióváltoztatásokkal a CI folyamatát szeretnénk leegyszerűsíteni és automatizálni. Erre jön a segítségünkre egy kényelmes, közismert plugin versions-maven-plugin — csatlakoztatjuk és elindítjuk

mvn -N versions:set -DnewVersion=2.0.1

és a maven mindent rendben megcsinál: végigfut a hierarchián felülről lefelé, minden verziót kicserél - gyönyörű! Most már csak fel kell emelni a pull-requestet, a kollégák átnézik a módosításokat, és gyorsan viszünk az trunk-ba. Gyorsan? Hát nem egészen. Párszáz pom.xml a felülvizsgálathoz, és ez nem számítva a kódot. Ezenkívül senki sem védett a merge-konfliktusoktól is, figyelembe véve a módosított fájlok nagy számát. Ezen a ponton meg kell említeni, hogy a CI folyamat során a verziók automatikusan módosulnak a funkciók változásával együtt, és nem külön.

Új lehetőségek

Egy ideig megnyugodtunk, és belenyugodva úgy éltünk, amíg a srácok a Maven Apache Project be nem vezették a mavenbe a 3.5.0-beta-1 verziótól kezdődően a úgynevezett "helyettesítők" (placeholders) támogatását. Ennek lényege, hogy pom.xml a projekt verziójának konkrét megadása helyett változókat használnak ${revision}, ${sha1} és ${changelist}. E tulajdonságok értékei vagy a <itt szükséges ahhoz, hogy az adminisztrátor értesítést kapjon a build és tesztelési eredményekről, mint a folyamat tulajdonosa.> elemben adják meg, vagy a rendszerváltozókon keresztül is meghatározhatók

mvn -Drevision=2.0.0 clean package

A rendszerváltozók értékei nagyobb prioritással bírnak, mint azok az értékek, amelyeket a <itt szükséges ahhoz, hogy az adminisztrátor értesítést kapjon a build és tesztelési eredményekről, mint a folyamat tulajdonosa.> elemben határoztak meg.

Szülő
<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>Első CI Barátságos<\/name>
  <version>${revision}${sha1}${changelist}<\/version>
  …
  <properties>
    <revision>1.3.1<\/revision>
    <changelist>-SNAPSHOT<\/changelist>
    <sha1\>
  <\/properties>
<\/project>

Gyermek
<project>
  <modelVersion>4.0.0<\/modelVersion>
  <parent>
    <groupId>org.apache.maven.ci<\/groupId>
    <artifactId>ci-parent<\/artifactId>
    <version>${revision}${sha1}${changelist}<\/version>
  <\/parent>
  <groupId>org.apache.maven.ci<\/groupId>
  <artifactId>ci-child<\/artifactId>
   …
<\/project>

Ha a 2.0.0-SNAPSHOT verziót szeretnéd összeállítani, akkor egyszerűen használj

mvn -Drevision=2.0.0 clean package

Ha kiadást szeretnél készíteni, akkor egyszerűen nullázd a SNAPSHOT-ot

mvn -Dchangelist= clean package

*A fenti példák a cikkből származnak Maven Apache Project weboldalán találhatók.

Kegyetlen valóság

Minden szép és jó, ideje megtapasztalni a megelégedettséget, de nem. Kiderül, hogy az install és deploy esetében ez a módszer nem működik, mivel a közzétett artefaktumok leírásában nem fogják helyettesíteni ${revision} annak értékét, és a maven nem fogja tudni, miről van szó egyáltalán.

<parent>
    <groupId>org.apache<\/groupId>
    <artifactId>apache<\/artifactId>
    <version>${revision}<\/version>
<\/parent>

Fény az alagút végén

Meg kell találni a probléma megoldását. A helyzetet megmenthetné flatten-maven-plugin. Ez a plugin lehetővé teszi az összes változó engedélyezését a pom-ban, de egyúttal rengeteg más információt is eltávolít, amely csak a build során szükséges, és nem szükséges a közzétett artefaktumok más projektekbe való importálásához. A plugin "kiigazítja" az összes parent-child függőséget, és így lapos pom-t eredményez, amely tartalmazza mindazt, amire szükség van. A hátrány az volt, hogy túl sok "felesleges" elemet vág ki, ami számunkra teljesen elfogadhatatlan volt. A plugin fejlesztése során végül kiderült, hogy nem vagyunk egyedül ebben az univerzumban, és már 2018 augusztusában a plugin GitHub repository-jában egy pull-requestet hoztak létre azzal a kívánsággal, hogy lehetőséget adjanak arra, hogy magunk határozzuk meg, hogyan kell "megsérteni" a pom.xml-t. A fejlesztők meghallgatták a kérdéseinket, és már decemberben, az 1.1.0-ás új verzió megjelenésével a flatten-maven-pluginhoz új üzemmód került bevezetésre, a resolveCiFriendliesOnly, amely pontosan akkor vált időszerűvé – megtartja a pom.xml-t olyannak, amilyen. <version> és engedélyezi ${revision}, ${sha1} és ${changelist}.

Plugin hozzáadása a projekthez

<plugins>
  <plugin>
    org.codehaus.mojo
    flatten-maven-plugin
    1.1.0
    <configuration>
      true
      <flattenMode>resolveCiFriendliesOnly</flattenMode>
    </configuration>
    <executions>
      <execution>
        flatten
        process-resources
        <goals>
          flatten
        </goals>
      </execution>
      <execution>
        flatten.clean
        clean
        <goals>
          clean
        </goals>
      </execution>
    </executions>
  </plugin>
</plugins>

Kész!

Boldog befejezés

Mostantól, hogy megváltoztassuk az egész projekt verzióját, és erről tájékoztassuk az összes függőséget, csupán a <revision> elem szerkesztésére van szükség egyetlen gyökérfájlban. pom.xmlÍgy nem kell több tucat ilyen fájl módosításával bajlódni, csak egy egyet. És ezzel elhárul a szükségesség versions-maven-plugin.

Forrás: habr.com