Despre noi
La 1C dezvoltăm nu doar o platformă pe и , dar și aplicații Java - în special noul mediu de dezvoltare bazat pe Eclipse și un server de mesagerie profund integrat cu platforma - .
Intrare
Folosim cel mai adesea maven ca sistem de compilare pentru aplicații Java, iar în acest scurt articol am dori să vorbim despre una dintre problemele cu care a trebuit să ne confruntăm în procesul de organizare a dezvoltării și despre abordarea care ne-a permis să depășim acest lucru. problemă.
Cerințe preliminare și flux de lucru
Datorită specificului dezvoltării în proiectele noastre maven, folosim destul de multe module, dependențe și proiecte copil. Numărul de fișiere pom dintr-un arbore poate fi de zeci sau chiar sute.
S-ar părea: nu e mare lucru, l-au creat o dată și au uitat de el. Dacă trebuie să modificați sau să adăugați ceva în toate fișierele simultan, există o mulțime de instrumente convenabile în editori și IDE-uri. Care este cea mai frecventă modificare obișnuită a pom.xml? Credem că schimbările în versiunile și dependențele proiectului. Poate cineva va dori să se certe cu asta, dar aceasta este exact situația la noi. Motivul constă în faptul că, împreună cu nucleul, dezvoltăm simultan multe dintre propriile biblioteci, iar pentru reproductibilitatea constantă a rezultatelor construcției și testării, folosirea instantaneelor nu ni se pare o abordare convenabilă. Din acest motiv, este necesar să creșteți numărul versiunii în proiecte cu fiecare build.
De asemenea, din când în când, un dezvoltator trebuie să-și construiască propria ramură a unei biblioteci și să verifice funcționalitatea acesteia față de toate dependențele, pentru care trebuie să schimbe manual versiunea tuturor acestora.
Soluție inițială
Cu modificări atât de frecvente și multiple de versiuni, vreau să simplific și să automatizez procesul din CI. Aici vine în ajutor un plugin convenabil și bine-cunoscut. versions-maven-plugin - conectați-l și lansați-l
mvn -N versiuni:set -DnewVersion=2.0.1
iar Maven va face totul așa cum trebuie: va trece prin ierarhie de sus în jos, înlocuind toate versiunile - frumusețe! Acum, tot ce rămâne este să ridici o cerere de tragere, colegii vor revizui modificările și te poți înscrie rapid în trunchi. Repede? Indiferent cum ar fi. Câteva sute pom.xml pentru revizuire, iar acesta nu ia în calcul codul. În plus, nimeni nu este ferit de conflictele de îmbinare cu un număr atât de mare de fișiere modificate. Trebuie remarcat aici că în procesul CI, modificările versiunii apar automat împreună cu modificările de funcționalitate și nu cumva separat.
Caracteristici noi
O vreme ne-am linistit si, resemnati, am trait asa pana la baietii de la Începând cu versiunea 3.5.0-beta-1, Maven nu a inclus suport pentru așa-numiții „substituenți”. Esența acestor înlocuitori este aceea pom.xml în loc de o indicație specifică a versiunii proiectului, sunt utilizate variabile ${revision}, ${sha1} и ${changelist}. Valorile acestor proprietăți în sine sunt setate fie în elementproprietăţi> sau pot fi definite printr-o proprietate a sistemului
mvn -Drevision=2.0.0 pachet curat
Valorile proprietăților sistemului au prioritate față de valorile definite înproprietăţi>.
Mamă
4.0.0
org.apache
apache
18
org.apache.maven.ci
ci-părinte
Prima CI Friendly
${revision}${sha1}${changelist}
...
1.3.1
-INSTANTANEU
Descendent
4.0.0
org.apache.maven.ci
ci-părinte
${revision}${sha1}${changelist}
org.apache.maven.ci
ci-copil
...
Dacă doriți să construiți versiunea 2.0.0-SNAPSHOT, atunci utilizați
mvn -Drevision=2.0.0 pachet curat
Dacă doriți să faceți o lansare, atunci pur și simplu resetați SNAPSHOT
mvn -Dchangelist= pachet curat
*Exemplele de mai sus sunt preluate din pe site-ul web al proiectului Maven Apache
realitatea dură
Totul este bine și sănătos, este timpul să simți un sentiment de satisfacție, dar nu. Se pare că această metodă nu va funcționa pentru instalare și implementare, deoarece nu va fi înlocuită în descrierile artefactelor publicate în depozit. ${revision} asupra semnificației sale și maven nu va mai înțelege despre ce este vorba.
org.apache
apache
${revision}
O lumină la capătul unui tunel
Trebuie să căutăm o soluție la problemă. Ar fi putut salva situația . Acest plugin rezolvă toate variabilele din pom, dar în același timp elimină o mulțime de alte informații care sunt necesare doar în timpul asamblarii și nu sunt necesare atunci când se importă artefacte publicate în alte proiecte. De asemenea, pluginul „îndreptează” toate dependențele părinte-copil și, ca rezultat, obțineți un pom plat care include tot ce aveți nevoie. Inconvenientul a fost ca taie prea mult „extra”, care nu ne convine deloc. După ce am studiat informațiile despre dezvoltarea acestui plugin, s-a dovedit că nu suntem singurii din univers, iar în august 2018, a fost creată o solicitare pull pe Github în depozitul de pluginuri cu dorința de a face posibilă acest lucru. pentru a determina pe cont propriu cum să „stricam” pom.xml. Dezvoltatorii au ascultat vocile celor care sufereau și deja în decembrie, odată cu lansarea noii versiuni 1.1.0, un nou mod, resolveCiFriendliesOnly, a apărut în plugin-ul flatten-maven, care era mai potrivit ca niciodată - pleacă pom.xml așa cum este, cu excepția elementului si permite ${revision}, ${sha1} и ${changelist}.
Adăugarea unui plugin la proiect
org.codehaus.mojo
flatten-maven-plugin
1.1.0
Adevărat
resolveCiFriendliesOnly
aplatiza
proces-resurse
aplatiza
aplatiza.curata
curat
curat
Gata!
Final fericit
De acum înainte, pentru a schimba versiunea întregului proiect și pentru a informa toate dependențele despre aceasta, trebuie doar să edităm elementulRevizuire> doar în rădăcină pom.xml. Nu o sută sau două dintre aceste fișiere cu aceeași modificare ajung la revizuire, ci unul. Ei bine, nu este nevoie de utilizare versions-maven-plugin.
Sursa: www.habr.com