om oss
Hos 1C utvikler vi ikke bare en plattform på и , men også Java-applikasjoner - spesielt det nye utviklingsmiljøet basert på Eclipse og en messenger-server dypt integrert med plattformen - .
Entry
Vi bruker oftest maven som et byggesystem for Java-applikasjoner, og i denne korte artikkelen vil vi gjerne snakke om et av problemene vi måtte møte i prosessen med å organisere utviklingen, og om tilnærmingen som gjorde at vi kunne overvinne dette problem.
Forutsetninger og arbeidsflyt
På grunn av utviklingen i våre maven-prosjekter, bruker vi ganske mange moduler, avhengigheter og barneprosjekter. Antallet pom-filer i ett tre kan være i titalls eller hundrevis.
Det ser ut til: ingen big deal, de skapte det en gang og glemte det. Hvis du trenger å endre eller legge til noe i alle filer samtidig, er det mange praktiske verktøy i redaktører og IDE-er. Hva er den vanligste endringen til pom.xml? Vi tror at endringer i prosjektversjoner og avhengigheter. Kanskje noen vil krangle med dette, men dette er akkurat situasjonen hos oss. Årsaken ligger i det faktum at vi, sammen med kjernen, samtidig utvikler mange av våre egne biblioteker, og for den konstante reproduserbarheten av bygge- og testresultater virker bruken av øyeblikksbilder ikke for oss som en praktisk tilnærming. Av denne grunn er det nødvendig å heve versjonsnummeret i prosjekter med hvert bygg.
Også, fra tid til annen, må en utvikler bygge sin egen gren av et bibliotek og sjekke funksjonaliteten mot alle avhengigheter, som han må manuelt endre versjonen av alle.
Opprinnelig løsning
Med slike hyppige og flere versjonsendringer ønsker jeg å forenkle og automatisere prosessen innenfor CI. Det er her en praktisk, velkjent plugin kommer til unnsetning. versjoner-maven-plugin - koble den til og start den
mvn -N versions:set -DnewVersion=2.0.1
og Maven vil gjøre alt som det skal: det vil løpe gjennom hierarkiet fra topp til bunn, og erstatte alle versjoner - skjønnhet! Nå gjenstår det bare å reise en pull-forespørsel, kolleger vil gjennomgå endringene, og du kan raskt bli med i bagasjerommet. Raskt? Uansett hvordan det er. Et par hundre pom.xml for gjennomgang, og dette teller ikke koden. I tillegg er ingen trygge for å slå sammen konflikter med et så stort antall endrede filer. Det skal bemerkes her at i CI-prosessen skjer versjonsendringer automatisk sammen med endringer i funksjonalitet, og ikke på en eller annen måte separat.
Nye funksjoner
En stund roet vi oss ned og etter å ha resignert, levde vi sånn til gutta fra Fra og med versjon 3.5.0-beta-1 inkluderte ikke Maven støtte for såkalte "plassholdere". Essensen av disse erstatningene er det pom.xml i stedet for en spesifikk indikasjon på prosjektversjonen, brukes variabler ${revisjon}, ${sha1} и ${changelist}. Verdiene til disse egenskapene er satt enten i elementetegenskaper>, eller de kan defineres gjennom en systemegenskap
mvn -Drevision=2.0.0 ren pakke
Systemegenskapsverdier har forrang over verdier definert iegenskaper>.
Foreldre
4.0.0
org.apache
apache
18
org.apache.maven.ci
ci-forelder
Første CI Friendly
${revision}${sha1}${changelist}
...
1.3.1
- STILLBILDE
Etterkommer
4.0.0
org.apache.maven.ci
ci-forelder
${revision}${sha1}${changelist}
org.apache.maven.ci
ci-barn
...
Hvis du vil bygge versjon 2.0.0-SNAPSHOT, er det bare å bruke
mvn -Drevision=2.0.0 ren pakke
Hvis du vil lage en utgivelse, er det bare å tilbakestille SNAPSHOT
mvn -Dchangelist= ren pakke
*Eksemplene ovenfor er hentet fra på nettstedet til Maven Apache Project
Brutal virkelighet
Alt er bra og sunt, det er på tide å føle en følelse av tilfredshet, men nei. Det viser seg at denne metoden ikke vil fungere for installasjon og distribusjon, siden den ikke vil bli erstattet i beskrivelsene av artefakter publisert i depotet ${revisjon} på sin mening og maven vil ikke lenger forstå hva det handler om.
org.apache
apache
${revisjon}
Et lys i enden av en tunnel
Vi må se etter en løsning på problemet. Kunne reddet situasjonen . Denne plugin løser alle variabler i pom, men kutter samtidig ut mye annen informasjon som bare er nødvendig under montering og ikke er nødvendig når du importerer publiserte artefakter til andre prosjekter. Pluginen "retter ut" alle foreldre-barn-avhengigheter, og som et resultat får du en flat pom som inneholder alt du trenger. Ulempen var at det kutter ut for mye "ekstra", noe som ikke passet oss i det hele tatt. Etter å ha studert informasjonen om utviklingen av dette pluginet, viste det seg at vi ikke er de eneste i universet, og tilbake i august 2018 ble det opprettet en pull-forespørsel på Github i plugin-depotet med ønsket om å gjøre det mulig for å bestemme på egen hånd hvordan du kan "skjemme bort" pom.xml. Utviklerne lyttet til stemmene til de som lider, og allerede i desember, med utgivelsen av den nye versjonen 1.1.0, dukket det opp en ny modus, resolveCiFriendliesOnly, i flatten-maven-pluginen, som var mer egnet enn noensinne - den forlater pom.xml som den er, bortsett fra elementet og tillater ${revisjon}, ${sha1} и ${changelist}.
Legger til en plugin til prosjektet
org.codehaus.mojo
flatten-maven-plugin
1.1.0
ekte
løse CiFriendliesOnly
flate ut
prosess-ressurser
flate ut
flate.rengjør
ren
ren
Ferdig!
Lykkelig slutt
Fra nå av, for å endre versjonen av hele prosjektet og la alle avhengigheter få vite om det, trenger vi bare å redigere elementetrevisjon> i bare roten pom.xml. Ikke hundre eller to av disse filene med samme endring kommer frem til anmeldelsen, men én. Vel, det er ikke nødvendig å bruke versjoner-maven-plugin.
Kilde: www.habr.com