guri buruz
1C-n ez gara soilik plataforma bat garatzen on ΠΈ , baina baita Java aplikazioak - bereziki garapen-ingurune berria Eclipse eta plataforman oso integratuta dagoen mezulari zerbitzari batean oinarrituta - .
Sarrera
Gehienetan maven erabiltzen dugu Java aplikazioetarako eraikitze-sistema gisa, eta artikulu labur honetan garapena antolatzeko prozesuan aurre egin behar izan genuen arazoetako bati buruz hitz egin nahiko genuke, eta hori gainditzeko aukera eman zigun planteamenduaz. arazoa.
Aurrebaldintzak eta lan-fluxua
Gure maven proiektuen garapenaren berezitasunak direla eta, modulu, menpekotasun eta haur proiektu asko erabiltzen ditugu. Zuhaitz bateko pom fitxategien kopurua hamarnaka edo ehunkakoa izan daiteke.
Badirudi: gauza handirik ez, behin sortu zuten eta ahaztu egin ziren. Fitxategi guztietan zerbait aldatu edo gehitu behar baduzu aldi berean, tresna eroso asko daude editoreetan eta IDEetan. Zein da pom.xml-rako ohiko aldaketa ohikoena? Proiektuaren bertsioetan eta menpekotasunean aldaketak direla uste dugu. Beharbada norbaitek eztabaidatu nahi izango du hori, baina horixe da gure egoera. Arrazoia, nukleoarekin batera, aldi berean gure liburutegi propio asko garatzen ari garela da, eta eraikuntzaren eta proben emaitzen etengabeko errepikagarritasunagatik, argazkien erabilera ez zaigu erosoa iruditzen. Hori dela eta, beharrezkoa da bertsio-zenbakia igotzea proiektuetan eraikuntza bakoitzarekin.
Gainera, noizean behin, garatzaile batek liburutegi baten adar propioa eraiki behar du eta haren funtzionaltasuna egiaztatu behar du mendekotasun guztien aurrean, eta horretarako eskuz aldatu behar du guztien bertsioa.
Hasierako irtenbidea
Hain maiz eta hainbat bertsio-aldaketarekin, prozesua erraztu eta automatizatu nahi dut CI barruan. Hona hemen plugin eroso eta ezagun bat erreskatatzera. versions-maven-plugin - konektatu eta abiarazi
mvn -N bertsioak: set -DnewVersion=2.0.1
eta Mavenek dena behar duen bezala egingo du: goitik behera hierarkian zehar ibiliko da, bertsio guztiak ordezkatuz - edertasuna! Orain tira-eskaera bat planteatzea baino ez da geratzen, lankideek aldaketak berrikusiko dituzte, eta azkar sartu zaitezke enborrerantz. Azkar? Ez du axola nola den. Ehun pare bat pom.xml berrikusteko, eta hau ez da kodea zenbatzea. Horrez gain, inor ez dago seguru bateratze-gatazkatik aldatutako fitxategi kopuru handiarekin. Kontuan izan behar da hemen CI prozesuan bertsio-aldaketak automatikoki gertatzen direla funtzionalitate-aldaketekin batera, eta ez nolabait bereizita.
Ezaugarri berriak
Pixka bat lasaitu ginen eta, erresignatuta, horrela bizi izan ginen mutilak 3.5.0-beta-1 bertsiotik hasita, Maven-ek ez zuen "leku-markak" deiturikoen laguntzarik sartu. Ordezko hauen funtsa hori da pom.xml proiektuaren bertsioaren adierazgarri zehatz baten ordez, aldagaiak erabiltzen dira ${revision}, ${sha1} ΠΈ ${changelist}. Propietate hauen balioak elementuan ezartzen dirapropietate>, edo sistemaren propietate baten bidez definitu daitezke
mvn -Drevision=2.0.0 pakete garbia
Sistemaren propietateen balioek lehentasuna dute atalean definitutako balioen aurreanpropietate>.
Guraso
4.0.0
org.apache
apache
18
org.apache.maven.ci
ci-guraso
Lehen CI Lagunartekoa
${revision}${sha1}${changelist}
...
1.3.1
-ARGAZKIA
Oinordekoa
4.0.0
org.apache.maven.ci
ci-guraso
${revision}${sha1}${changelist}
org.apache.maven.ci
ci-ume
...
2.0.0-SNAPSHOT bertsioa eraiki nahi baduzu, erabili
mvn -Drevision=2.0.0 pakete garbia
Argitalpen bat egin nahi baduzu, berrezarri SNAPSHOT
mvn -Dchangelist= pakete garbia
*Goiko adibideak hemendik hartuak dira Maven Apache Project webgunean
Errealitate gogorra
Dena ona eta osasuntsua da, poztasun bat sentitzeko garaia da, baina ez. Ematen du metodo honek ez duela funtzionatuko instalatzeko eta zabaltzeko, ez baita ordezkatuko biltegian argitaratutako artefaktuen deskribapenetan. ${revision} bere esanahiaren gainean eta maven-ek ez du gehiago ulertuko zer den guztia.
org.apache
apache
${revision}
Argi bat tunel baten amaieran
Arazoari irtenbidea bilatu behar diogu. Egoera salba zezakeen . Plugin honek pom-eko aldagai guztiak ebazten ditu, baina, aldi berean, muntaian bakarrik beharrezkoa den eta argitaratutako artefaktuak beste proiektu batzuetara inportatzean beharrezkoa ez den beste informazio asko kentzen du. Pluginak gurasoen eta seme-alaben mendekotasun guztiak ere "zuzentzen" ditu, eta, ondorioz, behar duzun guztia biltzen duen pom laua lortzen duzu. Eragozpena izan zen βgehiegizkoβ gehiegi mozten zuela, eta hori ez zitzaigun batere komeni. Plugin honen garapenari buruzko informazioa aztertu ondoren, ikusi zen ez garela unibertsoan bakarrak, eta 2018ko abuztuan, Github-en pull-request bat sortu zen pluginen biltegian posible egiteko gogoarekin. pom.xml nola "hondatu" gure kabuz zehazteko. Garatzaileek sufritzen zutenen ahotsa entzun zuten, eta abenduan jada, 1.1.0 bertsio berria kaleratuta, modu berri bat, resolveCiFriendliesOnly, flatten-maven-plugin-ean agertu zen, inoiz baino egokiagoa zena - uzten du. pom.xml dagoen bezala, elementua izan ezik eta ahalbidetzen du ${revision}, ${sha1} ΠΈ ${changelist}.
Proiektuari plugin bat gehitzea
org.codehaus.mojo
berdindu-maven-plugin
1.1.0
egia
ebatziCiFriendliesOnly
berdindu
prozesu-baliabideak
berdindu
berdindu.garbitu
garbi
garbi
Bukatu da!
Amaiera zoriontsua
Hemendik aurrera, proiektu osoaren bertsioa aldatzeko eta menpekotasun guztiak horren berri emateko, elementua editatu besterik ez dugu egin behar.revision> erroan besterik ez pom.xml. Aldaketa bera duten fitxategi horietako ehun edo bi ez dira berrikuspenera iristen, bat baizik. Beno, ez dago erabili beharrik versions-maven-plugin.
Iturria: www.habr.com