Om os
Hos 1C udvikler vi ikke kun en platform på и , men også Java-applikationer - især det nye udviklingsmiljø baseret på Eclipse og en messenger-server dybt integreret med platformen - .
Indrejse
Vi bruger oftest maven som et byggesystem til Java-applikationer, og i denne korte artikel vil vi gerne tale om et af de problemer, vi skulle stå over for i processen med at organisere udviklingen, og om den tilgang, der gjorde det muligt for os at overvinde dette. problem.
Forudsætninger og arbejdsgang
På grund af udviklingen i vores maven-projekter, bruger vi en hel del moduler, afhængigheder og børneprojekter. Antallet af pom-filer i et træ kan være i tiere eller endda hundrede.
Det ser ud til: ingen big deal, de skabte det en gang og glemte det. Hvis du har brug for at ændre eller tilføje noget i alle filer på én gang, er der en masse praktiske værktøjer i editorer og IDE'er. Hvad er den mest almindelige regelmæssige ændring af pom.xml? Vi mener, at ændringer i projektversioner og afhængigheder. Måske vil nogen argumentere for dette, men dette er præcis situationen med os. Årsagen ligger i det faktum, at vi sammen med kernen samtidig udvikler mange af vores egne biblioteker, og for den konstante reproducerbarhed af bygge- og testresultater forekommer det ikke at bruge snapshots som en bekvem tilgang. Af denne grund er det nødvendigt at hæve versionsnummeret i projekter med hver build.
Fra tid til anden skal en udvikler også bygge sin egen gren af et bibliotek og kontrollere dets funktionalitet i forhold til alle afhængigheder, for hvilke han manuelt skal ændre versionen af dem alle.
Indledende løsning
Med så hyppige og flere versionsændringer ønsker jeg at forenkle og automatisere processen inden for CI. Det er her et bekvemt, velkendt plugin kommer til undsætning. versions-maven-plugin - tilslut den og start den
mvn -N versions:set -DnewVersion=2.0.1
og Maven vil gøre alt, som det skal: det vil løbe gennem hierarkiet fra top til bund og erstatte alle versioner - skønhed! Nu er der kun tilbage at rejse en pull-anmodning, kolleger vil gennemgå ændringerne, og du kan hurtigt komme med i bagagerummet. Hurtigt? Uanset hvordan det er. Et par hundrede pom.xml til gennemgang, og dette tæller ikke koden. Derudover er ingen sikker på at flette konflikter med et så stort antal ændrede filer. Det skal her bemærkes, at i CI-processen sker versionsændringer automatisk sammen med ændringer i funktionalitet og ikke på en eller anden måde separat.
Nye funktioner
Et stykke tid faldt vi til ro, og efter at have resigneret, levede vi sådan indtil fyrene fra Fra version 3.5.0-beta-1 inkluderede Maven ikke understøttelse af såkaldte "pladsholdere". Essensen af disse erstatninger er det pom.xml i stedet for en specifik angivelse af projektversionen, anvendes variabler ${revision}, ${sha1} и ${changelist}. Værdierne af disse egenskaber selv er sat enten i elementetegenskaber>, eller de kan defineres gennem en systemegenskab
mvn -Drevision=2.0.0 ren pakke
Systemegenskabsværdier har forrang over værdier defineret iegenskaber>.
Forælder
4.0.0
org.apache
apache
18
org.apache.maven.ci
ci-forælder
Første CI venlige
${revision}${sha1}${changelist}
...
1.3.1
- SNAPSHOT
Efterkommer
4.0.0
org.apache.maven.ci
ci-forælder
${revision}${sha1}${changelist}
org.apache.maven.ci
ci-barn
...
Hvis du vil bygge version 2.0.0-SNAPSHOT, så brug bare
mvn -Drevision=2.0.0 ren pakke
Hvis du vil lave en udgivelse, skal du blot nulstille SNAPSHOT
mvn -Dchangelist= ren pakke
*Eksemplerne ovenfor er taget fra på Maven Apache Projects hjemmeside
Hård virkelighed
Alt er godt og sundt, det er tid til at føle en følelse af tilfredshed, men nej. Det viser sig, at denne metode ikke vil fungere til installation og udrulning, da den ikke vil blive erstattet i beskrivelserne af artefakter offentliggjort i depotet ${revision} på sin mening og maven vil ikke længere forstå, hvad det handler om.
org.apache
apache
${revision}
Et lys for enden af en tunnel
Vi skal lede efter en løsning på problemet. Kunne have reddet situationen . Dette plugin løser alle variabler i pom'en, men skærer samtidig en masse anden information ud, som kun er nødvendig under montering og ikke er nødvendig, når du importerer publicerede artefakter til andre projekter. Pluginnet "retter ud" også alle forældre-barn-afhængigheder, og som et resultat får du en flad pom, der indeholder alt, hvad du har brug for. Ulejligheden var, at den skærer for meget “ekstra”, hvilket slet ikke passede os. Efter at have studeret informationen om udviklingen af dette plugin viste det sig, at vi ikke er de eneste i universet, og tilbage i august 2018 blev der oprettet en pull-request på Github i plugin-lageret med ønsket om at gøre det muligt for på egen hånd at bestemme, hvordan man "forkæler" pom.xml. Udviklerne lyttede til de lidendes stemmer, og allerede i december, med udgivelsen af den nye version 1.1.0, dukkede en ny tilstand op, resolveCiFriendliesOnly, i flatten-maven-pluginet, som var mere egnet end nogensinde - det forlader pom.xml som den er, bortset fra elementet og tillader ${revision}, ${sha1} и ${changelist}.
Tilføjelse af et plugin til projektet
org.codehaus.mojo
flatten-maven-plugin
1.1.0
rigtigt
løs kun CiFriendlies
flade
proces-ressourcer
flade
flade.rengør
ren
ren
Udført!
Lykkelig slutning
Fra nu af, for at ændre versionen af hele projektet og lade alle afhængigheder vide om det, skal vi bare redigere elementetrevision> kun i roden pom.xml. Ikke et hundrede eller to af disse filer med samme ændring ankommer til gennemgangen, men én. Nå, der er ingen grund til at bruge versions-maven-plugin.
Kilde: www.habr.com