О нас
Ĉe 1C ni disvolvas ne nur platformon sur и , sed ankaŭ Java-aplikoj - precipe la nova evolumedio bazita sur Eclipse kaj mesaĝa servilo profunde integrita kun la platformo - .
eniro
Ni plej ofte uzas maven kiel konstrusistemon por Java-aplikoj, kaj en ĉi tiu mallonga artikolo ni ŝatus paroli pri unu el la problemoj, kiujn ni devis alfronti en la procezo de organizado de disvolviĝo, kaj pri la aliro, kiu permesis al ni venki ĉi tion. problemo.
Antaŭkondiĉoj kaj laborfluo
Pro la specifaĵoj de evoluo en niaj maven-projektoj, ni uzas sufiĉe multajn modulojn, dependecojn kaj infanajn projektojn. La nombro da pom-dosieroj en unu arbo povas esti en la dekoj aŭ eĉ centoj.
Ŝajnus: ne gravas, ili kreis ĝin unufoje kaj forgesis pri ĝi. Se vi bezonas ŝanĝi aŭ aldoni ion en ĉiuj dosieroj samtempe, ekzistas multaj oportunaj iloj en redaktiloj kaj IDEoj. Kio estas la plej ofta regula ŝanĝo al pom.xml? Ni kredas, ke ŝanĝoj en projektoversioj kaj dependecoj. Eble iu volos disputi pri tio, sed ĉi tio estas ĝuste la situacio ĉe ni. La kialo kuŝas en tio, ke, kune kun la kerno, ni samtempe disvolvas multajn el niaj propraj bibliotekoj, kaj por la konstanta reproduktebleco de konstruaj kaj testaj rezultoj, la uzo de momentfotoj ne ŝajnas al ni oportuna aliro. Tial, estas necese levi la version-numeron en projektoj kun ĉiu konstruo.
Ankaŭ, de tempo al tempo, programisto bezonas konstrui sian propran branĉon de biblioteko kaj kontroli ĝian funkciecon kontraŭ ĉiuj dependecoj, por kiuj li devas permane ŝanĝi la version de ĉiuj ili.
Komenca solvo
Kun tiaj oftaj kaj multoblaj versioŝanĝoj, mi volas simpligi kaj aŭtomatigi la procezon ene de CI. Jen kie oportuna, konata kromaĵo venas al la savo. versions-maven-plugin - konektu ĝin kaj lanĉu ĝin
mvn -N versions:set -DnewVersion=2.0.1
kaj Maven faros ĉion kiel ĝi devus: ĝi trairos la hierarkion de supre ĝis malsupre, anstataŭigante ĉiujn versiojn - beleco! Nun restas nur levi peton, kolegoj revizios la ŝanĝojn, kaj vi povas rapide aliĝi al la trunko. Ĉu rapide? Ne gravas kiel ĝi estas. Paro da centoj pom.xml por revizio, kaj ĉi tio ne kalkulas la kodon. Krome, neniu estas sekura kontraŭ kunfandaj konfliktoj kun tiom granda nombro da ŝanĝitaj dosieroj. Oni devas rimarki ĉi tie, ke en la CI-procezo, versioŝanĝoj okazas aŭtomate kune kun ŝanĝoj en funkcieco, kaj ne iel aparte.
Novaj funkcioj
Dum kelka tempo ni trankviliĝis kaj, rezignaciinte, ni vivis tiel ĝis la uloj de Maven, komencante kun versio 3.5.0-beta-1, ne inkludis subtenon por tiel nomataj "lokteniloj" de versioj. La esenco de ĉi tiuj anstataŭaĵoj estas tio pom.xml anstataŭ specifa indiko de la projekta versio oni uzas variablojn ${revizio}, ${sha1} и ${ŝanĝlisto}. La valoroj de ĉi tiuj propraĵoj mem estas fiksitaj aŭ en la elementoproprietoj>, aŭ ili povas esti difinitaj per sistema propraĵo
mvn -Drevision=2.0.0 pura pako
Sistemaj posedaĵvaloroj havas prioritaton super valoroj difinitaj enproprietoj>.
Gepatro
4.0.0
org.apache
apache
18
org.apache.maven.ci
ci-gepatro
Unua CI Amika
${revision}${sha1}${changelist}
...
1.3.1
- MOMENTOJN
Posteulo
4.0.0
org.apache.maven.ci
ci-gepatro
${revision}${sha1}${changelist}
org.apache.maven.ci
ci-infano
...
Se vi volas konstrui version 2.0.0-SNAPSHOT, do simple uzu
mvn -Drevision=2.0.0 pura pako
Se vi volas fari liberigon, tiam simple restarigi SNAPSHOT
mvn -Dchangelist= pura pako
*La supraj ekzemploj estas prenitaj de en la retejo de Maven Apache Project
Severa realo
Ĉio estas bona kaj sana, estas tempo por senti senton de kontento, sed ne. Rezultas, ke ĉi tiu metodo ne funkcios por instali kaj disfaldi, ĉar ĝi ne estos anstataŭigita en la priskriboj de artefaktoj publikigitaj en la deponejo. ${revizio} pri ĝia signifo kaj maven ne plu komprenos pri kio temas.
org.apache
apache
${revizio}
Lumo en la fino de tunelo
Ni devas serĉi solvon al la problemo. Povus savi la situacion . Ĉi tiu kromaĵo solvas ĉiujn variablojn en la pom, sed samtempe fortranĉas multajn aliajn informojn, kiuj nur bezonas dum muntado kaj ne necesas dum importado de publikigitaj artefaktoj en aliajn projektojn. La kromaĵo ankaŭ "rektigas" ĉiujn gepatro-infanajn dependecojn, kaj kiel rezulto, vi ricevas platan pomon, kiu inkluzivas ĉion, kion vi bezonas. La ĝeno estis, ke ĝi eltranĉas tro da "kromaĵo", kio tute ne konvenis al ni. Post studi la informojn pri la disvolviĝo de ĉi tiu kromaĵo, montriĝis, ke ni ne estas la solaj en la universo, kaj reen en aŭgusto 2018, pull-peto estis kreita sur Github en la kromprogramo kun la deziro ebligi ĝin. por determini memstare kiel "difekti" pom.xml. La programistoj aŭskultis la voĉojn de tiuj suferantoj, kaj jam en decembro, kun la ĵeto de la nova versio 1.1.0, nova reĝimo, resolveCiFriendliesOnly, aperis en la flatten-maven-kromaĵo, kiu estis pli taŭga ol iam - ĝi foriras pom.xml tia, krom la elemento kaj permesas ${revizio}, ${sha1} и ${ŝanĝlisto}.
Aldonante kromprogramon al la projekto
org.codehaus.mojo
flatten-maven-plugin
1.1.0
vera
solvuCiFriendliesOnly
platigi
procezo-rimedoj
platigi
platigi.purigi
purigi
purigi
Farita!
Feliĉa fino
De nun, por ŝanĝi la version de la tuta projekto kaj sciigi pri ĝi ĉiujn dependecojn, ni nur bezonas redakti la elementon.revizio> nur en la radiko pom.xml. Ne cent aŭ du el ĉi tiuj dosieroj kun la sama ŝanĝo alvenas al la revizio, sed unu. Nu, ne necesas uzi versions-maven-plugin.
fonto: www.habr.com