Oer ús
By 1C ûntwikkelje wy net allinich in platfoarm op и , mar ek Java-applikaasjes - benammen de nije ûntwikkelingsomjouwing basearre op Eclipse en in messenger-tsjinner djip yntegreare mei it platfoarm - .
Ynlieding
Wy brûke meastentiids maven as in buildsysteem foar Java-applikaasjes, en yn dit koarte artikel wolle wy prate oer ien fan 'e problemen dy't wy te krijen hawwe yn it proses fan it organisearjen fan ûntwikkeling, en oer de oanpak dy't ús dit koe oerwinnen. probleem.
Betingsten en workflow
Fanwegen de spesifikaasjes fan ûntwikkeling yn ús maven-projekten brûke wy in protte modules, ôfhinklikens en berneprojekten. It oantal pom-bestannen yn ien beam kin yn 'e tsientallen of sels hûnderten wêze.
It soe lykje: gjin big deal, se hawwe it ien kear makke en fergetten. As jo wat yn alle bestannen tagelyk moatte feroarje of tafoegje, binne d'r in protte handige ark yn bewurkers en IDE's. Wat is de meast foarkommende reguliere feroaring yn pom.xml? Wy leauwe dat feroarings yn projekt ferzjes en ôfhinklikens. Faaks wol ien hjirmei pleitsje, mar dit is krekt de situaasje by ús. De reden leit yn it feit dat wy, tegearre mei de kernel, tagelyk in protte fan ús eigen bibleteken ûntwikkelje, en foar de konstante reprodusearberens fan bou- en testresultaten liket it gebrûk fan snapshots ús net in handige oanpak. Om dizze reden is it nedich om it ferzjenûmer te ferheegjen yn projekten mei elke build.
Ek moat in ûntwikkelder fan tiid ta tiid syn eigen tûke fan in bibleteek bouwe en de funksjonaliteit kontrolearje tsjin alle ôfhinklikens, wêrfoar hy de ferzje fan allegear mei de hân moat feroarje.
Inisjele oplossing
Mei sokke faak en meardere ferzjeswizigingen wol ik it proses binnen CI ferienfâldigje en automatisearje. Dit is wêr't in handige, bekende plugin ta de rêding komt. versions-maven-plugin - ferbine it en start it
mvn -N ferzjes: set -DnewVersion=2.0.1
en Maven sil alles dwaan sa't it moat: it sil fan boppen nei ûnderen troch de hiërargy rinne, alle ferzjes ferfange - skientme! No is alles wat oerbliuwt om in pull-fersyk op te heljen, kollega's sille de wizigingen besjen, en jo kinne fluch meidwaan oan 'e kofferbak. Gau? Gjin saak hoe't it is. In pear hûndert pom.xml foar resinsje, en dit is net telle de koade. Dêrnjonken is gjinien feilich foar fúzjekonflikten mei sa'n grut oantal feroare bestannen. It moat hjir opmurken wurde dat yn it CI-proses ferzjewizigingen automatysk foarkomme tegearre mei feroaringen yn funksjonaliteit, en net op ien of oare manier apart.
Nije funksjes
In skoftke wy bedarren en, hawwende ússels ûntslach, wy wenne sa oant de jonges út Fanôf ferzje 3.5.0-beta-1, hat Maven gjin stipe foar saneamde "plakhâlders". De essinsje fan dizze ferfangers is dat pom.xml ynstee fan in spesifike oantsjutting fan it projekt ferzje, fariabelen wurde brûkt ${revision}, ${sha1} и ${changelist}. De wearden fan dizze eigenskippen sels wurde ynsteld yn it eleminteigenskippen>, of se kinne wurde definieare fia in systeemeigenskip
mvn -Drevision=2.0.0 skjin pakket
Wearden fan systeemeigendom hawwe foarrang boppe wearden definieare yneigenskippen>.
Ouder
4.0.0
org.apache
apache
18
org.apache.maven.ci
ci-âlder
Earste CI Friendly
${revision}${sha1}${changelist}
...
1.3.1
- SNAPSHOT
Neikommeling
4.0.0
org.apache.maven.ci
ci-âlder
${revision}${sha1}${changelist}
org.apache.maven.ci
ci-bern
...
As jo ferzje 2.0.0-SNAPSHOT bouwe wolle, brûk dan gewoan
mvn -Drevision=2.0.0 skjin pakket
As jo in release wolle meitsje, set dan gewoan SNAPSHOT werom
mvn -Dchangelist= skjin pakket
*De foarbylden hjirboppe binne nommen út op 'e webside fan Maven Apache Project
Heftige werklikheid
Alles is goed en sûn, it is tiid om in gefoel fan tefredenheid te fielen, mar nee. It docht bliken dat dizze metoade net sil wurkje foar ynstallaasje en ynset, om't it net sil wurde ferfongen yn 'e beskriuwingen fan artefakten publisearre yn it repository ${revision} op syn betsjutting en maven sil net mear begripe wêr't it om giet.
org.apache
apache
${revision}
In ljocht yn 'e ein fan in tunnel
Wy moatte sykje nei in oplossing foar it probleem. Koe de situaasje rêde hawwe . Dizze plugin lost alle fariabelen yn 'e pom op, mar snijt tagelyk in protte oare ynformaasje út dy't allinich nedich is by montage en is net nedich by it ymportearjen fan publisearre artefakten yn oare projekten. De plugin "rjochtet" ek alle âlder-bern-ôfhinklikens, en as gefolch krije jo in platte pom dy't alles omfettet wat jo nedich binne. It oerlêst wie dat it tefolle "ekstra" útknipt, wat ús hielendal net paste. Nei it bestudearjen fan de ynformaasje oer de ûntwikkeling fan dit plugin, die bliken dat wy net de iennigen yn it universum binne, en werom yn augustus 2018 waard in pull-fersyk makke op Github yn it plugin repository mei de winsk om it mooglik te meitsjen om op ús eigen te bepalen hoe't jo pom.xml. De ûntwikkelders harken nei de stimmen fan dy lijen, en al yn desimber, mei de frijlitting fan 'e nije ferzje 1.1.0, ferskynde in nije modus, resolveCiFriendliesOnly, yn 'e flatten-maven-plugin, dy't geskikter wie as ea - it ferlit pom.xml as is, útsein it elemint en tastean ${revision}, ${sha1} и ${changelist}.
In plugin tafoegje oan it projekt
org.codehaus.mojo
flatten-maven-plugin
1.1.0
wier
resolveCiFriendliesOnly
ôfflakken
proses-boarnen
ôfflakken
flatten.skjin
skjin
skjin
Done!
Lokkich ein
Fanôf no moatte wy it elemint gewoan bewurkje om de ferzje fan it heule projekt te feroarjen en alle ôfhinklikens derfan te litten witte.revyzje> yn gewoan de woartel pom.xml. Net hûndert of twa fan dizze triemmen mei deselde feroaring komme by de resinsje, mar ien. No, it is net nedich om te brûken versions-maven-plugin.
Boarne: www.habr.com