O nas
Pri 1C ne razvijamo samo platforme o и , temveč tudi aplikacije Java - zlasti novo razvojno okolje temelji na Eclipse in messenger strežniku, ki je globoko integriran s platformo - .
Začetek
Maven najpogosteje uporabljamo kot gradbeni sistem za aplikacije Java in v tem kratkem članku bi radi govorili o eni od težav, s katerimi smo se morali soočiti v procesu organizacije razvoja, in o pristopu, ki nam je omogočil, da smo to premagali. problem.
Predpogoji in potek dela
Zaradi specifike razvoja v naših maven projektih uporabljamo precej modulov, odvisnosti in podrejenih projektov. Število pom datotek v enem drevesu je lahko v desetinah ali celo stotinah.
Zdi se: nič hudega, ustvarili so ga enkrat in pozabili na to. Če morate nekaj spremeniti ali dodati v vse datoteke hkrati, je v urejevalnikih in IDE veliko priročnih orodij. Katera je najpogostejša redna sprememba pom.xml? Verjamemo, da spremembe v različicah projekta in odvisnosti. Morda bo kdo želel s tem polemizirati, a pri nas je točno tako. Razlog je v tem, da skupaj z jedrom hkrati razvijamo številne lastne knjižnice in za stalno ponovljivost rezultatov gradnje in testiranja se nam uporaba posnetkov ne zdi primeren pristop. Zaradi tega je treba z vsako gradnjo povečati številko različice v projektih.
Poleg tega mora razvijalec od časa do časa zgraditi lastno vejo knjižnice in preveriti njeno funkcionalnost glede na vse odvisnosti, za kar mora ročno spremeniti različico vseh.
Začetna rešitev
S tako pogostimi in večkratnimi spremembami različice želim poenostaviti in avtomatizirati proces znotraj CI. Tu na pomoč priskoči priročen, dobro poznan vtičnik. različice-maven-plugin - povežite ga in zaženite
mvn -N različice:set -DnewVersion=2.0.1
in Maven bo naredil vse, kot je treba: tekel bo po hierarhiji od vrha do dna in zamenjal vse različice - lepota! Zdaj ostane le še dvig zahteve za vlečenje, sodelavci bodo pregledali spremembe in hitro se lahko pridružite deblu. Hitro? Ne glede na to, kako je. Nekaj sto pom.xml za pregled in to ne šteje kode. Poleg tega nihče ni varen pred spori spajanja s tako velikim številom spremenjenih datotek. Tu je treba opozoriti, da se v procesu CI spremembe različice zgodijo samodejno skupaj s spremembami v funkcionalnosti in ne nekako ločeno.
Nove funkcije
Za nekaj časa smo se umirili in, ko smo se sprijaznili, tako živeli, dokler fantje iz Od različice 3.5.0-beta-1 naprej Maven ni vključeval podpore za tako imenovane »placeholders«. Bistvo teh nadomestkov je v tem pom.xml namesto specifične navedbe različice projekta se uporabljajo spremenljivke ${revizija}, ${sha1} и ${changelist}. Vrednosti teh lastnosti so same nastavljene v elementuLastnosti> ali pa jih je mogoče definirati prek sistemske lastnosti
mvn -Drevision=2.0.0 čisti paket
Vrednosti sistemskih lastnosti imajo prednost pred vrednostmi, definiranimi vLastnosti>.
Starš
4.0.0
org.apache
apache
18
org.apache.maven.ci
ci-starš
Prvi CI prijazen
${revision}${sha1}${changelist}
...
1.3.1
- POSNETEK
Potomec
4.0.0
org.apache.maven.ci
ci-starš
${revision}${sha1}${changelist}
org.apache.maven.ci
ci-otrok
...
Če želite zgraditi različico 2.0.0-SNAPSHOT, uporabite samo
mvn -Drevision=2.0.0 čisti paket
Če želite objaviti, potem preprosto ponastavite SNAPSHOT
mvn -Dchangelist= čisti paket
*Zgornji primeri so vzeti iz na spletni strani projekta Maven Apache
Huda realnost
Vse je dobro in zdravo, čas je za občutek zadovoljstva, a ne. Izkazalo se je, da ta metoda ne bo delovala pri namestitvi in uvajanju, ker ne bo nadomeščena v opisih artefaktov, objavljenih v repozitoriju ${revizija} na njegov pomen in maven ne bo več razumel, za kaj gre.
org.apache
apache
${revizija}
Luč na koncu tunela
Moramo poiskati rešitev problema. Lahko bi rešil situacijo . Ta vtičnik razreši vse spremenljivke v pomu, vendar hkrati izreže veliko drugih informacij, ki so potrebne samo med sestavljanjem in niso potrebne pri uvažanju objavljenih artefaktov v druge projekte. Vtičnik prav tako "poravna" vse odvisnosti med staršem in otrokom in kot rezultat dobite ravno pom, ki vključuje vse, kar potrebujete. Nevšečnost je bila v tem, da izreže preveč “ekstra”, kar nam nikakor ni ustrezalo. Po preučevanju informacij o razvoju tega vtičnika se je izkazalo, da nismo edini v vesolju, in že avgusta 2018 je bila na Githubu v repozitoriju vtičnikov ustvarjena zahteva za vlečenje z željo, da se to omogoči da sami določimo, kako »pokvariti« pom.xml. Razvijalci so prisluhnili glasovom trpečih in že decembra, z izidom nove različice 1.1.0, se je v vtičniku flatten-maven pojavil nov način resolveCiFriendliesOnly, ki je bil bolj primeren kot kdaj koli prej - pusti pom.xml, kot je, razen elementa in dovoljuje ${revizija}, ${sha1} и ${changelist}.
Dodajanje vtičnika v projekt
org.codehaus.mojo
vtičnik flatten-maven
1.1.0
prav
resolveCiFriendliesOnly
sploščiti
procesni viri
sploščiti
sploščiti.očistiti
čisto
čisto
Končano!
Srečen konec
Od zdaj naprej, če želimo spremeniti različico celotnega projekta in o tem obvestiti vse odvisnosti, moramo samo urediti elementRevizija> samo v korenu pom.xml. Na pregled ne pride sto ali dve teh datotek z isto spremembo, ampak ena. No, ni potrebe po uporabi različice-maven-plugin.
Vir: www.habr.com