Par mums
1C mēs izstrādājam ne tikai platformu par и , bet arī Java lietojumprogrammas, jo īpaši jaunā izstrādes vide pamatojoties uz Eclipse un Messenger serveri, kas ir dziļi integrēts ar platformu - .
Ieraksts
Mēs visbiežāk izmantojam maven kā Java lietojumprogrammu veidošanas sistēmu, un šajā īsajā rakstā mēs vēlamies runāt par vienu no problēmām, ar kurām mums bija jāsaskaras izstrādes organizēšanas procesā, un par pieeju, kas ļāva mums to pārvarēt. problēma.
Priekšnoteikumi un darbplūsma
Pateicoties attīstības specifikai mūsu maven projektos, mēs izmantojam diezgan daudz moduļu, atkarību un bērnu projektu. Pom failu skaits vienā kokā var būt desmitos vai pat simtos.
Šķiet: nekas, viņi to vienreiz izveidoja un aizmirsa. Ja jums ir jāmaina vai jāpievieno kaut kas visos failos vienlaikus, redaktoros un IDE ir daudz ērtu rīku. Kādas ir visizplatītākās regulārās izmaiņas vietnē pom.xml? Mēs uzskatām, ka izmaiņas projekta versijās un atkarībās. Varbūt kāds vēlēsies ar to strīdēties, bet pie mums situācija ir tieši tāda. Iemesls ir fakts, ka kopā ar kodolu mēs vienlaikus izstrādājam daudzas savas bibliotēkas, un, lai nodrošinātu nepārtrauktu izveides un testēšanas rezultātu reproducēšanu, momentuzņēmumu izmantošana mums nešķiet ērta pieeja. Šī iemesla dēļ ir nepieciešams palielināt versijas numuru projektos ar katru būvējumu.
Arī izstrādātājam laiku pa laikam ir jāizveido sava bibliotēkas filiāle un jāpārbauda tās funkcionalitāte pret visām atkarībām, tādēļ viņam ir manuāli jāmaina visu to versija.
Sākotnējais risinājums
Ar tik biežām un vairākām versiju izmaiņām es vēlos vienkāršot un automatizēt procesu CI. Šeit palīgā nāk ērts, labi zināms spraudnis. versions-maven-plugin - pievienojiet to un palaidiet to
mvn -N versions:set -DnewVersion=2.0.1
un Maven darīs visu kā nākas: brauks cauri hierarhijai no augšas uz leju, nomainot visas versijas - skaistums! Tagad atliek tikai izvirzīt pull pieprasījumu, kolēģi pārskatīs izmaiņas, un jūs varat ātri pievienoties stumbram. Ātri? Vienalga kā ir. Pāris simti pom.xml pārskatīšanai, un tas netiek skaitīts kods. Turklāt neviens nav pasargāts no sapludināšanas konfliktiem ar tik lielu mainīto failu skaitu. Šeit jāatzīmē, ka CI procesā versiju izmaiņas notiek automātiski kopā ar izmaiņām funkcionalitātē, nevis kaut kā atsevišķi.
Jaunas iespējas
Kādu laiku nomierinājāmies un, paši atkāpušies, tā dzīvojām līdz puiši no Sākot ar versiju 3.5.0-beta-1, Maven neietvēra tā saukto vietturu atbalstu. Šo aizstājēju būtība ir tāda pom.xml konkrētas projekta versijas norādes vietā tiek izmantoti mainīgie ${revision}, ${sha1} и ${changelist}. Pašu šo īpašību vērtības ir iestatītas vai nu elementāīpašības> vai arī tos var definēt, izmantojot sistēmas rekvizītu
mvn -Drevision=2.0.0 tīra pakotne
Sistēmas rekvizītu vērtībām ir prioritāte pār vērtībām, kas definētasīpašības>.
Vecāks
4.0.0
org.apache
apache
18
org.apache.maven.ci
ci-vecāks
Pirmais CI draudzīgs
${revision}${sha1}${changelist}
...
1.3.1
- MOMENTA SHOT
Pēcnācējs
4.0.0
org.apache.maven.ci
ci-vecāks
${revision}${sha1}${changelist}
org.apache.maven.ci
ci-bērns
...
Ja vēlaties izveidot versiju 2.0.0-SNAPSHOT, vienkārši izmantojiet
mvn -Drevision=2.0.0 tīra pakotne
Ja vēlaties izdot laidienu, vienkārši atiestatiet SNAPSHOT
mvn -Dchangelist= tīra pakotne
*Iepriekš minētie piemēri ir ņemti no Maven Apache Project vietnē
Skarba realitāte
Viss ir labi un veselīgi, laiks sajust gandarījumu, bet nē. Izrādās, ka šī metode nedarbosies instalēšanai un izvietošanai, jo tā netiks aizstāta repozitorijā publicētajos artefaktu aprakstos ${revision} par tā nozīmi, un maven vairs nesapratīs, par ko ir runa.
org.apache
apache
${revision}
Gaisma tuneļa galā
Mums jāmeklē problēmas risinājums. Varēja situāciju glābt . Šis spraudnis atrisina visus pom mainīgos, bet tajā pašā laikā izgriež daudz citas informācijas, kas ir nepieciešama tikai montāžas laikā un nav nepieciešama, importējot publicētos artefaktus citos projektos. Spraudnis arī "izlīdzina" visas vecāku un bērnu atkarības, un rezultātā jūs iegūstat plakanu komplektu, kurā ir viss nepieciešamais. Neērtības sagādāja tas, ka tas izgriež pārāk daudz “papildu”, kas mums nemaz nederēja. Izpētot informāciju par šī spraudņa izstrādi, izrādījās, ka mēs neesam vienīgie Visumā, un vēl 2018. gada augustā Github spraudņu repozitorijā tika izveidots pull-request ar vēlmi to padarīt iespējamu. lai paši noteiktu, kā “sabojāt” pom.xml. Izstrādātāji ieklausījās cietušo balsīs, un jau decembrī līdz ar jaunās versijas 1.1.0 izlaišanu flatten-maven-pluginā parādījās jauns režīms solveCiFriendliesOnly, kas bija piemērotāks nekā jebkad agrāk - tas atstāj. pom.xml kā ir, izņemot elementu un atļauj ${revision}, ${sha1} и ${changelist}.
Spraudņa pievienošana projektam
org.codehaus.mojo
flatten-maven-plugin
1.1.0
taisnība
atrisinātCiFriendliesOnly
saplacināt
process-resursi
saplacināt
saplacināt.tīrs
tīrs
tīrs
Gatavs!
Laimīgas beigas
No šī brīža, lai mainītu visa projekta versiju un informētu par to visas atkarības, mums vienkārši jārediģē elementsrevīzija> tikai saknē pom.xml. Pārskatā nonāk nevis simts vai divi no šiem failiem ar vienādām izmaiņām, bet gan viens. Nu nevajag izmantot versions-maven-plugin.
Avots: www.habr.com