Firmast
1C ei arenda mitte ainult platvormi edasi и , aga ka Java-rakendusi – eelkõige uut arenduskeskkonda põhineb Eclipse'il ja platvormiga sügavalt integreeritud Messengeri serveril - .
Kanne
Kõige sagedamini kasutame mavenit Java-rakenduste ehitussüsteemina ja selles lühikeses artiklis tahaksime rääkida ühest probleemist, millega arenduse korraldamisel silmitsi tulime, ja lähenemisviisist, mis võimaldas meil sellest üle saada. probleem.
Eeltingimused ja töövoog
Tulenevalt arenduse spetsiifikast oma mavenprojektides kasutame päris palju mooduleid, sõltuvusi ja lapsprojekte. Pom-failide arv ühes puus võib ulatuda kümnetesse või isegi sadadesse.
Näib: pole hullu, nad lõid selle kunagi ja unustasid selle. Kui teil on vaja kõigis failides korraga midagi muuta või lisada, on redaktorites ja IDE-des palju mugavaid tööriistu. Mis on pom.xml kõige tavalisem regulaarne muudatus? Usume, et muudatused projekti versioonides ja sõltuvustes. Võib-olla soovib keegi selle üle vaielda, kuid meie puhul on olukord täpselt selline. Põhjus peitub selles, et koos tuumaga arendame samaaegselt paljusid oma teeke ning ehitus- ja testimistulemuste pideva reprodutseeritavuse huvides ei tundu hetktõmmiste kasutamine meile mugav lähenemine. Sel põhjusel on vaja iga järguga projektides versiooninumbrit tõsta.
Samuti peab arendaja aeg-ajalt ehitama oma raamatukogu haru ja kontrollima selle funktsionaalsust kõigi sõltuvuste suhtes, mille jaoks peab ta kõigi nende versiooni käsitsi muutma.
Esialgne lahendus
Nii sagedaste ja mitmekordsete versioonimuudatustega tahan CI-s protsessi lihtsustada ja automatiseerida. Siin tuleb appi mugav, tuntud pistikprogramm. versions-maven-plugin - ühendage see ja käivitage see
mvn -N versioonid:set -DnewVersion=2.0.1
ja Maven teeb kõik nii nagu peab: jookseb läbi hierarhia ülevalt alla, asendades kõik versioonid – ilu! Nüüd ei jää muud üle, kui tõsta tõmbetaotlus, kolleegid vaatavad muudatused üle ja saad kiirelt pagasiruumiga liituda. Kiiresti? Ükskõik kuidas see on. Paarsada pom.xml ülevaatamiseks ja see ei arvesta koodi. Lisaks pole keegi kaitstud liitmiskonfliktide eest nii suure hulga muudetud failidega. Siinkohal tuleb märkida, et CI protsessis toimuvad versioonimuudatused automaatselt koos funktsionaalsuse muutustega, mitte kuidagi eraldi.
Uued funktsioonid
Tükk aega rahunesime maha ja olles ise üles astunud, elasime nii kuni kuttideni Alates versioonist 3.5.0-beta-1 ei sisaldanud Maven nn kohahoidjate tuge. Nende asendajate olemus seisneb selles pom.xml projekti versiooni konkreetse viite asemel kasutatakse muutujaid ${revision}, ${sha1} и ${changelist}. Nende omaduste väärtused määratakse kas elemendisomadused> või neid saab määratleda süsteemi atribuudi kaudu
mvn -Drevision=2.0.0 puhas pakett
Süsteemi atribuutide väärtused on ülimuslikud jaotises määratletud väärtuste eesomadused>.
Vanem
4.0.0
org.apache
apache
18
org.apache.maven.ci
ci-vanem
Esimene CI-sõbralik
${revision}${sha1}${changelist}
...
1.3.1
-SÄPES
Järeltulija
4.0.0
org.apache.maven.ci
ci-vanem
${revision}${sha1}${changelist}
org.apache.maven.ci
ci-laps
...
Kui soovite luua versiooni 2.0.0-SNAPSHOT, siis lihtsalt kasutage
mvn -Drevision=2.0.0 puhas pakett
Kui soovite väljalaset teha, lähtestage lihtsalt SNAPSHOT
mvn -Dchangelist= puhas pakett
* Ülaltoodud näited on võetud Maven Apache Projecti veebisaidil
Karm reaalsus
Kõik on hea ja terve, on aeg tunda rahulolu, aga ei. Selgub, et see meetod ei tööta installimisel ja juurutamisel, kuna seda ei asendata hoidlas avaldatud artefaktide kirjeldustes ${revision} selle tähendusest ja maven ei saa enam aru, milles see on.
org.apache
apache
${revision}
Valgus tunneli lõpus
Peame otsima probleemile lahendust. Oleks võinud olukorra päästa . See pistikprogramm lahendab kõik pomi muutujad, kuid lõikab samal ajal välja palju muud teavet, mida on vaja ainult koostamise ajal ja mida pole vaja avaldatud artefaktide importimisel teistesse projektidesse. Pistikprogramm "sirutab" ka kõik vanema ja lapse sõltuvused ja selle tulemusel saate lameda sisu, mis sisaldab kõike, mida vajate. Ebamugavuseks oli see, et see lõikab liiga palju "lisa", mis meile üldse ei sobinud. Pärast selle pistikprogrammi arendusteabe uurimist selgus, et me pole universumis ainsad ja juba augustis 2018 loodi Githubis pistikprogrammide hoidlas tõmbetaotlus sooviga see võimalikuks teha. et ise otsustada, kuidas pom.xml "rikkuda". Arendajad kuulasid kannatajate häält ja juba detsembris, uue versiooni 1.1.0 väljalaskmisega, ilmus flatten-maven-pluginasse uus režiim, solveCiFriendliesOnly, mis oli sobivam kui kunagi varem – see lahkub. pom.xml nagu on, välja arvatud element ja lubab ${revision}, ${sha1} и ${changelist}.
Plugina lisamine projekti
org.codehaus.mojo
flatten-maven-plugin
1.1.0
tõsi
lahendadaCiFriendliesOnly
lamedamaks
protsess-ressursid
lamedamaks
lamedamaks.puhastada
puhas
puhas
Valmis!
Õnnelik lõpp
Nüüdsest tuleb kogu projekti versiooni muutmiseks ja kõikidele sõltuvustele sellest teada andmiseks lihtsalt elementi redigeeridaläbivaatamine> ainult juurtes pom.xml. Ülevaatusele ei jõua mitte sada või kaks sama muudatusega faili, vaid üks. No pole vaja kasutada versions-maven-plugin.
Allikas: www.habr.com