Meer oor ons
By 1C ontwikkel ons nie net 'n platform nie op и , maar ook Java-toepassings - veral die nuwe ontwikkelingsomgewing gebaseer op Eclipse en 'n boodskapper-bediener wat diep geïntegreer is met die platform - .
Entry
Ons gebruik Maven meestal as 'n boustelsel vir Java-toepassings, en in hierdie kort artikel wil ons praat oor een van die probleme wat ons in die gesig moes staar in die proses om ontwikkeling te organiseer, en oor die benadering wat ons toegelaat het om dit te oorkom. probleem.
Voorvereistes en werkvloei
As gevolg van die besonderhede van ontwikkeling in ons maven-projekte, gebruik ons nogal baie modules, afhanklikhede en kinderprojekte. Die aantal pom-lêers in een boom kan in die tiene of selfs honderde wees.
Dit wil voorkom: geen groot probleem nie, hulle het dit een keer geskep en daarvan vergeet. As jy iets in alle lêers gelyktydig moet verander of byvoeg, is daar baie gerieflike hulpmiddels in redigeerders en IDE's. Wat is die algemeenste gereelde verandering na pom.xml? Ons glo dat veranderinge in projek weergawes en afhanklikhede. Miskien sal iemand hiermee wil stry, maar dit is presies die situasie met ons. Die rede lê in die feit dat ons, saam met die kern, terselfdertyd baie van ons eie biblioteke ontwikkel, en vir die konstante reproduceerbaarheid van bou- en toetsresultate lyk die gebruik van kiekies nie vir ons 'n gerieflike benadering nie. Om hierdie rede is dit nodig om die weergawenommer in projekte met elke bou te verhoog.
Ook moet 'n ontwikkelaar van tyd tot tyd sy eie tak van 'n biblioteek bou en die funksionaliteit daarvan teen alle afhanklikhede nagaan, waarvoor hy die weergawe van almal met die hand moet verander.
Aanvanklike oplossing
Met sulke gereelde en veelvuldige weergaweveranderings wil ek die proses binne CI vereenvoudig en outomatiseer. Dit is waar 'n gerieflike, bekende inprop tot die redding kom. weergawes-maven-plugin - koppel dit en begin dit
mvn -N weergawes:set -DnewVersion=2.0.1
en Maven sal alles doen soos dit moet: dit sal van bo na onder deur die hiërargie loop en alle weergawes vervang - skoonheid! Nou is al wat oorbly om 'n trekversoek te rig, kollegas sal die veranderinge hersien, en jy kan vinnig by die stam aansluit. Vinnig? Maak nie saak hoe dit is nie. 'n Paar honderd pom.xml vir hersiening, en dit tel nie die kode nie. Daarbenewens is niemand veilig teen samesmeltingskonflikte met so 'n groot aantal veranderde lêers nie. Daar moet hier kennis geneem word dat in die CI proses, weergawe veranderinge outomaties plaasvind saam met veranderinge in funksionaliteit, en nie een of ander manier afsonderlik.
Nuwe geleenthede
Vir 'n rukkie het ons rustig geraak en, nadat ons onsself bedank het, het ons so geleef totdat die ouens van Vanaf weergawe 3.5.0-beta-1 het Maven nie ondersteuning vir sogenaamde "plekhouers" ingesluit nie. Die essensie van hierdie plaasvervangers is dit pom.xml in plaas van 'n spesifieke aanduiding van die projekweergawe, word veranderlikes gebruik ${revision}, ${sha1} и ${changelist}. Die waardes van hierdie eiendomme self word in die element gesteleiendomme>, of hulle kan gedefinieer word deur 'n stelsel-eienskap
mvn -Drevision=2.0.0 skoon pakket
Stelseleiendomwaardes geniet voorrang bo waardes gedefinieer ineiendomme>.
Die ouer
4.0.0
org.apache
apache
18
org.apache.maven.ci
ci-ouer
Eerste CI Vriendelike
${revision}${sha1}${changelist}
...
1.3.1
- KIET
Afstammeling
4.0.0
org.apache.maven.ci
ci-ouer
${revision}${sha1}${changelist}
org.apache.maven.ci
ci-kind
...
As jy weergawe 2.0.0-SNAPSHOT wil bou, gebruik dan net
mvn -Drevision=2.0.0 skoon pakket
As jy 'n vrystelling wil maak, stel dan net SNAPSHOT terug
mvn -Dchangelist= skoon pakket
*Die voorbeelde hierbo is geneem uit op die Maven Apache Project-webwerf
Harde werklikheid
Alles is goed en gesond, dit is tyd om 'n gevoel van tevredenheid te voel, maar nee. Dit blyk dat hierdie metode nie sal werk vir installering en ontplooiing nie, aangesien dit nie vervang sal word in die beskrywings van artefakte wat in die bewaarplek gepubliseer is nie. ${revision} op sy betekenis en maven sal nie meer verstaan waaroor dit gaan nie.
org.apache
apache
${revision}
'n Lig aan die einde van 'n tonnel
Ons moet soek na 'n oplossing vir die probleem. Kon die situasie gered het . Hierdie inprop los alle veranderlikes in die pom op, maar sny terselfdertyd baie ander inligting uit wat slegs tydens samestelling benodig word en nie nodig is wanneer gepubliseerde artefakte in ander projekte ingevoer word nie. Die inprop "reguit" ook alle ouer-kind-afhanklikhede, en gevolglik kry jy 'n plat pom wat alles insluit wat jy nodig het. Die ongerief was dat dit te veel “ekstra” uitsny, wat ons glad nie gepas het nie. Nadat ons die inligting oor die ontwikkeling van hierdie inprop bestudeer het, het dit geblyk dat ons nie die enigstes in die heelal is nie, en terug in Augustus 2018 is 'n trekversoek op Github in die inpropbewaarplek geskep met die begeerte om dit moontlik te maak om op ons eie te bepaal hoe om pom.xml te “bederf”. Die ontwikkelaars het geluister na die stemme van diegene wat ly, en reeds in Desember, met die vrystelling van die nuwe weergawe 1.1.0, het 'n nuwe modus, resolveCiFriendliesOnly, in die plat-maven-inprop verskyn, wat meer geskik was as ooit - dit verlaat pom.xml soos dit is, behalwe vir die element en laat toe ${revision}, ${sha1} и ${changelist}.
Voeg 'n inprop by die projek
org.codehaus.mojo
plat-maven-plugin
1.1.0
waar
los CiFriendliesOnly op
afplat
proses-hulpbronne
afplat
plat.skoon
skoon
skoon
Gedoen!
Gelukkige einde
Van nou af, om die weergawe van die hele projek te verander en alle afhanklikhede daarvan te laat weet, hoef ons net die element te wysighersiening> net in die wortel pom.xml. Nie 'n honderd of twee van hierdie lêers met dieselfde verandering kom by die hersiening uit nie, maar een. Wel, dit is nie nodig om te gebruik nie weergawes-maven-plugin.
Bron: will.com