Alconost arbetar professionellt med
På 1C utvecklar vi inte bara plattformen till och , utan även applikationer på Java – speciellt en ny utvecklingsmiljö baserad på Eclipse och servern är djupt integrerad med plattformens meddelandetjänst – .
Inledning
Som byggsystem för Java-applikationer använder vi oftast Maven, och i denna korta artikel vill vi berätta om ett av de problem som vi stött på i utvecklingsorganiseringen och om den metod som gjorde det möjligt att övervinna problemet.
Förutsättningarna och arbetsflödet
Med hänsyn till särdragen i utvecklingen i våra Maven-projekt använder vi ganska många moduler, beroenden och underprojekt. Antalet pom-filer i ett enda träd kan räknas i dussin och till och med hundratals.
Det verkar inte vara så farligt – vi skapar dem en gång och glömmer dem. Om man behöver ändra eller lägga till något i alla filer på en gång finns det gott om användbara verktyg i redigerare och IDE. Men vad är den vanligaste regelbundna förändringen av pom.xml? Vi tror att det handlar om att ändra versioner av projektet och beroendena. Kanske kommer någon att vilja diskutera detta, men så här ser det ut för oss. Anledningen är att vi parallellt utvecklar många egna bibliotek vid sidan av kärnan, och för att ständigt reproducera resultaten av bygg och testning är användningen av snapshots inte ett bekvämt tillvägagångssätt för oss. Därför måste vi höja versionsnumret i projekten vid varje byggen.
Utvecklaren har också ibland behov av att bygga sin egen gren av något bibliotek och kontrollera dess funktionalitet för alla beroenden, vilket innebär att man manuellt får ändra versionen i alla dessa.
Den initiala lösningen
Med så frekventa och många förändringar av versioner vill man förenkla och automatisera processen inom CI. Här kommer en användbar och välkänd plugin till hjälp versions-maven-plugin – vi kopplar in den och kör
mvn -N versions:set -DnewVersion=2.0.1
och Maven gör allt som det ska: det går igenom hierarkin uppifrån och ner, byter ut alla versioner – vackert! Nu återstår det bara att skicka upp en pull-request, kollegorna granskar ändringarna, och så kan man snabbt gå med i trunk. Snabbt? Kanske inte. Några hundra pom.xml för recension, och detta utan att räkna med koden. Dessutom är ingen skyddad från merge-konflikter när det finns så många ändrade filer. Här bör det noteras att i CI-processen sker versionsändringar automatiskt tillsammans med förändringen av funktionalitet, och inte på något separat sätt.
Nya funktioner
Under en tid lugnade vi oss och, accepterande, levde vi så här tills killarna från började i maven från version 3.5.0-beta-1 att stödja så kallade "versionsersättare" (placeholders). Idén med dessa ersättare är att pom.xml snarare än ett konkret versionsangivande används variabler. ${revision}, ${sha1} och ${changelist}. Själva värdena för dessa egenskaper anges antingen i elementet <properties>, eller så kan de definieras genom systemegenskapen
mvn -Drevision=2.0.0 clean package
Värdena för systemegenskaper har företräde framför värden som definieras i <properties>.
Förälder
<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>
Barn
<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>
Om du vill bygga version 2.0.0-SNAPSHOT, så använder du helt enkelt
mvn -Drevision=2.0.0 clean package
Om du vill göra en release, så nollställer du bara SNAPSHOT
mvn -Dchangelist= clean package
*Exemplen ovan är tagna från den officiella webbplatsen för Maven Apache Project
Den hårda verkligheten
Allt är bra och fantastiskt, det är dags att känna tillfredsställelse, men nej. Det visar sig att för install och deploy fungerar inte den här metoden, eftersom i beskrivningarna av artefakterna som publiceras till lagret kommer det inte att bytas ut ${revision} mot dess värde, och maven kommer inte att förstå vad det handlar om.
<parent>
<groupId>org.apache<\/groupId>
<artifactId>apache<\/artifactId>
<version>${revision}<\/version>
<\/parent>
Ljus i slutet av tunneln
Vi måste leta efter en lösning på problemet. Situationen skulle kunna räddas av . Den här pluginen tillåter alla variabler i pom, men skär också bort en hel del annan information som bara behövs vid byggandet och inte vid import av publicerade artefakter till andra projekt. Dessutom "utjämnar" pluginen alla parent-child beroenden, och resultatet blir platta pom som inkluderar allt som behövs. Nackdelen var att den skär bort för mycket "överflödig" information som inte passade oss alls. Efter att ha studerat informationen om utvecklingen av denna plugin, visade det sig att vi inte var ensamma i universum, och redan i augusti 2018 skapades en pull-request i pluginens GitHub-repositorium med önskemålet att ge möjlighet att själva definiera hur man vill "förstöra" pom.xml. Utvecklarna lyssnade på rösterna hos dem som sökte, och redan i december med lanseringen av den nya versionen 1.1.0 kom ett nytt läge resolveCiFriendliesOnly till flatten-maven-plugin, vilket kom lägligt – det lämnar pom.xml som den är, förutom elementet <version> och tillåter ${revision}, ${sha1} och ${changelist}.
Vi lägger till pluginen i projektet
<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>
Klart!
Lyckligt slut
Från och med nu, för att ändra versionen av hela projektet och informera alla beroenden om det, behöver vi bara redigera elementet <revision> i bara en rot pom.xml. Vid granskning kommer det inte en hundra eller två av dessa filer med samma ändring, utan en. Dessutom försvinner behovet av att använda versions-maven-plugin.
Källa: habr.com
