om oss
På 1C utvecklar vi inte bara en plattform på и , men även Java-applikationer - i synnerhet den nya utvecklingsmiljön baserad på Eclipse och en messenger-server som är djupt integrerad med plattformen - .
Entry
Vi använder oftast Maven som ett byggsystem för Java-applikationer, och i den här korta artikeln skulle vi vilja prata om ett av problemen som vi var tvungna att möta i processen att organisera utvecklingen, och om tillvägagångssättet som gjorde det möjligt för oss att övervinna detta problem.
Förutsättningar och arbetsflöde
På grund av utvecklingen i våra maven-projekt använder vi en hel del moduler, beroenden och barnprojekt. Antalet pom-filer i ett träd kan vara i tiotals eller till och med hundratals.
Det verkar: ingen stor grej, de skapade den en gång och glömde bort den. Om du behöver ändra eller lägga till något i alla filer på en gång, finns det många praktiska verktyg i redigerare och IDE. Vilken är den vanligaste regelbundna ändringen av pom.xml? Vi tror att förändringar i projektversioner och beroenden. Kanske kommer någon att vilja argumentera med detta, men det är precis så här med oss. Anledningen ligger i det faktum att vi, tillsammans med kärnan, samtidigt utvecklar många av våra egna bibliotek, och för den ständiga reproducerbarheten av bygg- och testresultat verkar användningen av ögonblicksbilder inte vara ett bekvämt tillvägagångssätt. Av denna anledning är det nödvändigt att höja versionsnumret i projekt med varje build.
Då och då måste en utvecklare också bygga sin egen gren av ett bibliotek och kontrollera dess funktionalitet mot alla beroenden, för vilka han måste ändra versionen av alla manuellt.
Initial lösning
Med så frekventa och flera versionsändringar vill jag förenkla och automatisera processen inom CI. Det är här ett bekvämt, välkänt plugin kommer till undsättning. versions-maven-plugin - anslut den och starta den
mvn -N versions:set -DnewVersion=2.0.1
och Maven kommer att göra allt som det ska: det kommer att gå genom hierarkin från topp till botten och ersätta alla versioner - skönhet! Nu återstår bara att ta upp en pull-förfrågan, kollegor kommer att granska ändringarna och du kan snabbt gå med i trunk. Snabbt? Hur det än är. Ett par hundra pom.xml för granskning, och detta räknar inte koden. Dessutom är ingen säker från att slå samman konflikter med ett så stort antal ändrade filer. Det bör noteras här att i CI-processen sker versionsändringar automatiskt tillsammans med ändringar i funktionalitet, och inte på något sätt separat.
Nya funktioner
Ett tag lugnade vi ner oss och efter att ha sagt upp oss levde vi så tills killarna från Från och med version 3.5.0-beta-1 inkluderade Maven inte stöd för så kallade "platshållare". Kärnan i dessa substitut är det pom.xml istället för en specifik indikation på projektversionen används variabler ${revision}, ${sha1} и ${changelist}. Värdena för dessa egenskaper ställs antingen in i elementetegenskaper> eller så kan de definieras genom en systemegenskap
mvn -Drevision=2.0.0 rent paket
Systemegenskapsvärden har företräde framför värden som definieras iegenskaper>.
Förälder
4.0.0
org.apache
apache
18
org.apache.maven.ci
ci-förälder
Första CI Friendly
${revision}${sha1}${changelist}
.
1.3.1
-SNAPSBILD
Ättling
4.0.0
org.apache.maven.ci
ci-förälder
${revision}${sha1}${changelist}
org.apache.maven.ci
ci-barn
.
Om du vill bygga version 2.0.0-SNAPSHOT, använd bara
mvn -Drevision=2.0.0 rent paket
Om du vill göra en release är det bara att återställa SNAPSHOT
mvn -Dchangelist= rent paket
*Exemplen ovan är hämtade från på Maven Apache Projects webbplats
hård verklighet
Allt är bra och hälsosamt, det är dags att känna en känsla av tillfredsställelse, men nej. Det visar sig att den här metoden inte kommer att fungera för installation och driftsättning, eftersom den inte kommer att ersättas i beskrivningarna av artefakter som publiceras i förvaret ${revision} på dess mening och maven kommer inte längre att förstå vad det handlar om.
org.apache
apache
${revision}
Ett ljus i slutet av en tunnel
Vi måste leta efter en lösning på problemet. Kunde ha räddat situationen . Detta plugin löser alla variabler i pom, men klipper samtidigt bort mycket annan information som bara behövs under montering och som inte behövs när man importerar publicerade artefakter till andra projekt. Pluginet "rätar ut" alla föräldrar-barn-beroenden, och som ett resultat får du en platt pom som innehåller allt du behöver. Besväret var att det skär ut för mycket "extra", vilket inte passade oss alls. Efter att ha studerat informationen om utvecklingen av detta plugin visade det sig att vi inte är de enda i universum, och redan i augusti 2018 skapades en pull-request på Github i plugin-förrådet med önskan att göra det möjligt för att på egen hand bestämma hur man "skämmer bort" pom.xml. Utvecklarna lyssnade på rösterna från de lidande, och redan i december, med lanseringen av den nya versionen 1.1.0, dök ett nytt läge, resolveCiFriendliesOnly, upp i flatten-maven-plugin, som var mer lämplig än någonsin - det lämnar pom.xml som den är, förutom elementet och tillåter ${revision}, ${sha1} и ${changelist}.
Lägger till ett plugin till projektet
org.codehaus.mojo
flatten-maven-plugin
1.1.0
Sann
resolveCiFriendliesOnly
platta
process-resurser
platta
platta.ren
rena
rena
Klart!
Lyckligt slut
Från och med nu, för att ändra versionen av hela projektet och låta alla beroenden veta om det, behöver vi bara redigera elementetrevidering> i bara roten pom.xml. Inte hundra eller två av dessa filer med samma ändring kommer fram till granskningen, utan en. Tja, det finns ingen anledning att använda versions-maven-plugin.
Källa: will.com