🥇Experiența utilizării flatten-maven-plugin pentru simplificarea versiunii în proiectele maven

Despre noi

La 1C dezvoltăm nu doar platforma 1C: Enterprise pe C++ și JavaScript, ci și aplicații pe Java – în special un nou mediu de dezvoltare Instrumente de Dezvoltare Enterprise bazat pe Eclipse și serverul este profund integrat cu platforma de mesagerie – Sisteme de Interacțiune.

Introducere

Ca sistem de construire a aplicațiilor Java, folosim cel mai adesea maven, iar în această mică articol dorim să vă povestim despre una dintre problemele cu care ne-am confruntat în procesul de organizare a dezvoltării și despre abordarea care ne-a permis să depășim această problemă.

Presupoziții și flux de lucru

Având în vedere specificul dezvoltării în proiectele noastre maven, folosim destul de multe module, dependențe și proiecte secundare. Numărul de fișiere pom într-un singur arbore poate fi estimat de zeci și chiar sute.

Se părea că: nu este nimic grav, am creat o dată și am uitat. Dacă este necesar să schimbăm sau să adăugăm ceva în toate fișierele deodată, există o mulțime de instrumente convenabile în editori și IDE-uri. Și care este cea mai frecventă modificare regulată a pom.xml? Credem că este schimbarea versiunilor proiectului și a dependențelor. Este posibil ca cineva să dorească să conteste acest lucru, dar la noi lucrurile stau exact așa. Motivul stă în faptul că, pe lângă nucleu, dezvoltăm în paralel multe biblioteci proprii și pentru reproducerea constantă a rezultatelor de construire și testare, folosirea snapshot-urilor nu ni se pare o abordare convenabilă. Din acest motiv, suntem nevoiți să ridicăm numărul versiunii în proiecte la fiecare construire.

De asemenea, de câte ori dezvoltatorul are nevoie să construiască ramura unei biblioteci și să verifice funcționalitatea acesteia în toate dependențele, pentru care trebuie să schimbe manual versiunea în toate.

Soluția inițială

Cu atâtea modificări frecvente și multiple ale versiunilor, procesul în cadrul CI dorește să fie simplificat și automatizat. Aici intervine un plugin cunoscut și convenabil versions-maven-plugin – îl conectăm și lansăm

mvn -N versions:set -DnewVersion=2.0.1

și maven va face totul cum trebuie: va parcurge ierarhia de sus în jos, va schimba toate versiunile – frumos! Acum rămâne să creăm pull-request-ul, colegii vor revizui modificările și ne putem integra rapid în trunk. Rapid? Nu prea. Câteva sute pom.xml la recenzare, și asta fără a lua în considerare codul. În plus, nimeni nu este sigur împotriva conflictelor de fuziune atunci când numărul fișierelor modificate este atât de mare. Aici trebuie menționat că, în procesul CI, modificările versiunilor se realizează automat împreună cu modificarea funcționalității, și nu separat.

Funcționalități noi

O perioadă de timp ne-am liniștit și, împăcându-ne, am trăit așa până când băieții de la Proiectul Maven Apache au inclus în maven, începând cu versiunea 3.5.0-beta-1, suport pentru așa-numitele „înlocuitoare” ale versiunilor (placeholders). Esența acestor înlocuitoare este că pom.xml în loc de o indicare concretă a versiunii proiectului sunt folosite variabilele ${revision}, ${sha1} și ${changelist}. Valorile acestor proprietăți sunt stabilite fie în elementul <properties>, fie pot fi definite printr-o proprietate de sistem

mvn -Drevision=2.0.0 clean package

Valorile proprietăților de sistem au prioritate față de valorile definite în <properties>.

Părinte
<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>1.3.1<\/revision>
    <changelist>-SNAPSHOT<\/changelist>
    <sha1\/>
  <\/properties>
<\/project>

Descendent
<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>

Dacă dorim să construim versiunea 2.0.0-SNAPSHOT, atunci pur și simplu folosim

mvn -Drevision=2.0.0 clean package

Dacă dorim să facem un release, atunci pur și simplu resetăm SNAPSHOT

mvn -Dchangelist= clean package

*Exemplele de mai sus sunt preluate de la recomandările sunt aplicabile coronavirusurilor în general și COVID-19 în particular. Așadar, recomand să descărcați și să printați articolul (pentru cei interesați de acest subiect). de pe site-ul Proiectului Maven Apache

Realitatea dură

Totul este bine și frumos, este timpul să experimentăm un sentiment de satisfacție, dar nu. Se pare că pentru install și deploy acest mod nu va funcționa, deoarece în descrierile artefactelor publicate în repository nu va fi înlocuit ${revision} cu valoarea ei și maven ulterior nu va înțelege despre ce este vorba.

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

Lumina de la capătul tunelului

Trebuie să căutăm o soluție la problemă. Situația ar putea fi salvată de flatten-maven-plugin. Acest plugin permite toate variabilele în pom, dar totodată elimină o mulțime de alte informații care sunt necesare doar în timpul compilării și nu sunt necesare la importarea artefactelor publicate în alte proiecte. De asemenea, pluginul „aliniază” toate dependențele parent-child, iar la final rezultă pom-uri plate, care includ tot ceea ce este necesar. Inconvenientul a fost că elimină „de prisos” prea mult, ceea ce nu ne-a convenit deloc. După studierea informațiilor despre dezvoltarea acestui plugin, s-a dovedit că nu suntem singurii în univers, iar în august 2018, în depozitul pluginului de pe GitHub a fost creat un pull-request cu dorința de a face posibilă definirea personalizată a modului în care trebuie „personalizat” pom.xml. Dezvoltatorii au ascultat vocile celor dornici, și deja în decembrie, cu lansarea noii versiuni 1.1.0, în flatten-maven-plugin a apărut un nou mod resolveCiFriendliesOnly, care a venit ca o mănușă – el lasă pom.xml așa cum este, cu excepția elementului <version> și permite ${revision}, ${sha1} și ${changelist}.

Adăugăm pluginul în proiect

<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>

Gata!

Sfârșit fericit

De acum înainte, pentru a schimba versiunea întregului proiect și a informa toate dependențele despre aceasta, trebuie doar să edităm elementul <revision> într-un singur pom rădăcină pom.xml. La recenzare nu vine o sută sau două de aceste fișiere cu aceeași modificare, ci unul. Ei bine, nu mai este nevoie de utilizarea versions-maven-plugin.

Sursa: habr.com