Om os
I 1C udvikler vi ikke kun platformen og få en fungerende kommando. og , men også applikationer i Java – især det nye udviklingsmiljø baseret på Eclipse og serveren dybt integreret med platformens messenger – .
Introduktion
Som byggesystem for Java-applikationer bruger vi oftest maven, og i denne lille artikel vil vi gerne fortælle om et af de problemer, vi stødte på i udviklingsprocessen, og om den tilgang, der gjorde det muligt at overvinde dette problem.
Forudsætninger og arbejdsgang
På grund af specifikationen af udviklingen i vores maven-projekter bruger vi en del moduler, afhængigheder og underprojekter. Antallet af pom-filer i et enkelt træ kan tælles i dusinvis og endda hundredvis.
Det kunne synes, at: det er ikke så slemt, man opretter det én gang og glemmer det. Hvis man skal ændre eller tilføje noget i alle filer samtidigt, findes der mange praktiske værktøjer i redaktører og IDE'er. Hvad er den mest almindelige regelmæssige ændring af pom.xml? Vi mener, at ændringen af versioner af projektet og afhængigheder. Måske vil nogen ønske at diskutere dette, men sådan står det til hos os. Årsagen er, at vi parallelt med kernen udvikler mange egne biblioteker, og for konstant reproducerbarhed af bygge- og testresultaterne finder vi ikke brugen af snapshots tilfredsstillende. Af denne grund skal vi hæve versionsnummeret i projekterne ved hver bygge.
Derudover opstår der fra tid til anden behov for udvikleren at samle sin gren af et eller andet bibliotek og kontrollere dens funktionalitet på tværs af alle afhængigheder, hvilket kræver, at man manuelt ændrer versionen i alle.
Den oprindelige løsning
Med så hyppige og mange versioneringsændringer ønsker man at forenkle og automatisere processen inden for CI. Her kommer en praktisk, velkendt plugin til hjælp versions-maven-plugin – vi tilslutter det og kører
mvn -N versions:set -DnewVersion=2.0.1
Maven klarer alt som det skal: den løber gennem hierarkiet fra top til bund, ændrer alle versioner — ren skønhed! Nu er det kun tilbage at løfte en pull-request, kollegerne vil se på ændringerne, og så kan vi hurtigt integrere i trunk. Hurtigt? Hvordan kan det være? Et par hundrede. pom.xml til review, og det er ikke engang medregnet koden. Desuden er ingen beskyttet mod merge-konflikter med så mange ændrede filer. Her skal det bemærkes, at i CI-processen sker ændringer af versioner automatisk sammen med ændringer i funktionalitet, ikke på en separat måde.
Nye funktioner
I et stykke tid blev vi rolige og levede med det, indtil fyrene fra inkorporerede såkaldte »version replacements« (pladsholdere) i Maven fra version 3.5.0-beta-1. Essensen af disse pladsholdere er, at pom.xml i stedet for at specificere en bestemt version af projektet bruges variabler ${revision}, ${sha1} og ${changelist}. Værdierne for disse egenskaber er enten angivet i elementet <properties>, eller de kan defineres gennem et systemegenskab
mvn -Drevision=2.0.0 clean package
Systemegenskaber har forrang over værdier defineret i <properties>.
Foræ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>
Afkom
<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>
Hvis du vil bygge version 2.0.0-SNAPSHOT, så brug bare
mvn -Drevision=2.0.0 clean package
Hvis du vil lave en release, så nulstiller du bare SNAPSHOT
mvn -Dchangelist= clean package
*Eksemplerne ovenfor er taget fra på Maven Apache Project's hjemmeside
Den barske realitet
Alt går fint, og det er tid til at føle tilfredshed, men nej. Det viser sig, at denne metode ikke virker til install og deploy, da beskrivelserne af de artefakter, der offentliggøres i repositoriet, ikke ændres ${revision} til dens værdi, og Maven vil ikke forstå, hvad det hele handler om.
<parent>
<groupId>org.apache<\/groupId>
<artifactId>apache<\/artifactId>
<version>${revision}<\/version>
<\/parent>
Lys for enden af tunnelen
Vi må finde en løsning på problemet. Situationen kunne være reddet af . Denne plugin gør det muligt at aktivere alle variable i pom, men skærer samtidig en masse anden information ud, som kun er nødvendig under bygningen og ikke er nødvendig ved import af offentliggjorte artefakter til andre projekter. Derudover 'udjævner' plugin'en alle parent-child afhængigheder, hvilket resulterer i flade pom'er, der inkluderer alt, hvad der er nødvendigt. Ulempen var, at den skar for meget 'overflødigt' ud, hvilket virkelig generede os. Efter at have undersøgt oplysningerne om udviklingen af denne plugin, viste det sig, at vi ikke var de eneste i universet, og allerede i august 2018 blev der oprettet en pull-anmodning i plugin'ens GitHub-repositorium med ønsket om at kunne definere selv, hvordan man skulle 'ødelægge' pom.xml. Udviklerne lyttede til de trængende, og allerede i december, med udgivelsen af den nye version 1.1.0, blev der tilføjet en ny tilstand resolveCiFriendliesOnly til flatten-maven-plugin, som kom som kaldet - den lader pom.xml være som den er, bortset fra elementet <version> og tillader ${revision}, ${sha1} og ${changelist}.
Vi tilføjer plugin'en til 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>
Færdig!
Happy end
Fremover skal vi for at ændre versionen af hele projektet og informere alle afhængigheder kun redigere elementet <revision> i kun den ene rod pom.xml. Til anmeldelse kommer der ikke en hundrede eller to af disse filer med ens ændringer, men kun én. Og det er ikke længere nødvendigt at bruge versions-maven-plugin.
Kilde: habr.com
