O nama
U 1C ne razvijamo samo platformu
Ulazak
Maven najčešće koristimo kao sustav za izgradnju Java aplikacija, au ovom kratkom članku željeli bismo govoriti o jednom od problema s kojima smo se morali suočiti u procesu organizacije razvoja te o pristupu koji nam je omogućio da to prevladamo. problem.
Preduvjeti i tijek rada
Zbog specifičnosti razvoja u našim maven projektima koristimo dosta modula, ovisnosti i podređenih projekata. Broj pom datoteka u jednom stablu može biti u desecima ili čak stotinama.
Reklo bi se: ništa strašno, jednom su ga stvorili i zaboravili. Ako trebate promijeniti ili dodati nešto u svim datotekama odjednom, postoji mnogo praktičnih alata u uređivačima i IDE-ima. Koja je najčešća redovita promjena u pom.xml? Vjerujemo da promjene u verzijama projekta i ovisnosti. Možda će netko htjeti s tim polemizirati, ali kod nas je upravo takva situacija. Razlog leži u činjenici da, zajedno s kernelom, istovremeno razvijamo mnoge vlastite biblioteke, a za stalnu ponovljivost rezultata izgradnje i testiranja, korištenje snimki ne čini nam se prikladnim pristupom. Iz tog razloga, potrebno je povećati broj verzije u projektima sa svakom build-om.
Također, s vremena na vrijeme, programer mora izgraditi vlastitu granu biblioteke i provjeriti njezinu funkcionalnost u odnosu na sve ovisnosti, za što mora ručno promijeniti verziju svih njih.
Početno rješenje
Uz tako česte i višestruke promjene verzija, želim pojednostaviti i automatizirati proces unutar CI-ja. Ovdje u pomoć dolazi praktičan, dobro poznat dodatak. versions-maven-plugin - spojite ga i pokrenite
mvn -N verzije:set -DnewVersion=2.0.1
a Maven će učiniti sve kako treba: proći će kroz hijerarhiju od vrha do dna, zamjenjujući sve verzije - ljepota! Sada preostaje samo podići zahtjev za povlačenjem, kolege će pregledati promjene i možete se brzo pridružiti deblu. Brzo? Bez obzira kako je. Nekoliko stotina pom.xml za pregled, a to ne računa kod. Osim toga, nitko nije siguran od sukoba spajanja s tako velikim brojem promijenjenih datoteka. Ovdje treba napomenuti da se u CI procesu promjene verzija događaju automatski zajedno s promjenama u funkcionalnosti, a ne nekako zasebno.
Nove značajke
Nakratko smo se smirili i, pomirivši se, tako smo živjeli sve dok momci iz
mvn -Drevision=2.0.0 čisti paket
Vrijednosti svojstava sustava imaju prednost nad vrijednostima definiranim uSvojstva>.
Roditelj
4.0.0
org.apache
apache
18
org.apache.maven.ci
ci-roditelj
Prvi CI prijateljski
${revision}${sha1}${changelist}
...
1.3.1
-SNIMAK
Potomak
4.0.0
org.apache.maven.ci
ci-roditelj
${revision}${sha1}${changelist}
org.apache.maven.ci
ci-dijete
...
Ako želite izgraditi verziju 2.0.0-SNAPSHOT, onda samo koristite
mvn -Drevision=2.0.0 čisti paket
Ako želite objaviti, samo resetirajte SNAPSHOT
mvn -Dchangelist= čisti paket
*Gore navedeni primjeri preuzeti su iz
Gruba stvarnost
Sve je dobro i zdravo, vrijeme je da osjetite osjećaj zadovoljstva, ali ne. Ispostavilo se da ova metoda neće raditi za instalaciju i implementaciju, jer neće biti zamijenjena u opisima artefakata objavljenih u repozitoriju ${revizija} na njegovo značenje i maven više neće razumjeti o čemu se radi.
org.apache
apache
${revizija}
Svjetlo na kraju tunela
Moramo tražiti rješenje problema. Mogao je spasiti situaciju
Dodavanje dodatka projektu
org.codehaus.mojo
flatten-maven-plugin
1.1.0
pravi
resolveCiFriendliesOnly
izravnati
proces-resursi
izravnati
spljoštiti.očistiti
čist
čist
Gotovo!
Sretan završetak
Od sada, kako bismo promijenili verziju cijelog projekta i obavijestili sve ovisnosti o tome, samo trebamo urediti elementrevizija> samo u korijenu pom.xml. Na recenziju ne stiže sto ili dvije ovakvih datoteka s istom izmjenom, nego jedna. Pa, nema potrebe za korištenjem versions-maven-plugin.
Izvor: www.habr.com