Meist
1C-s me loobime mitte ainult platvormi . Tundub, et ja , vaid ka rakendusi Java-s – nimelt uut arenduskeskkonda Eclipse'i põhjal ja server, mis on sügavalt integreeritud sõnumirakendusega – .
Sissejuhatus
Java rakenduste koostamise süsteemina kasutame kõige sagedamini mavenit ja selles lühikeses artiklis soovime rääkida ühest probleemist, millega oleme arenduse korraldamisel silmitsi seisnud, ning lähenemisest, mis selle probleemi lahendamiseks aitas.
Eeltingimused ja tööprotsess
Kuna meie maven-projektide arendamise iseloom nõuab meilt palju mooduleid, sõltuvusi ja alprojektide kasutamist, võib ühe puu pom-failide arv ulatuda kümnete ja isegi sadade kaupa.
Tundub, et pole hullu, loodud üks kord ja unustatud. Kui tuleb midagi kõigis failides korrigeerida või lisada, on redigeerijates ja IDE-des palju mugavaid tööriistu. Aga mis on kõige levinum regulaarne muudatus pom.xml-is? Usume, et projektide ja sõltuvuste versioonide muutmine. Võib-olla keegi tahaks selle üle vaielda, aga meil on asi just nii. Põhjus peitub selles, et koos tuumaga arendame samal ajal palju oma teeke ja tulemuste pidev reprodutseeritavus kogumises ja testimises ei võimalda meil kasutada sniemikeid. Seetõttu peame iga koostamise ajal projektides versiooninumbrit tõstma.
Samuti tekib arendajal aeg-ajalt vajadus koguda oma haru mõnest raamatukogust ja kontrollida selle toimivust kõigi sõltuvuste osas, millega on vajalik manuaalselt muuta versioon kõigis neist.
Esialgne lahendus
Selliste sagedaste ja mitmekesiste versioonimuudatustega tahame CI käigus protsessi lihtsustada ja automatiseerida. Siin tuleb appi mugav ja tuntud plugin versions-maven-plugin — kutsume selle üles ja käivitame
mvn -N versions:set -DnewVersion=2.0.1
ja maven teeb kõik nagu peab: jookseb puu ülevalt alla, asendab kõik versioonid — ilus! Nüüd peab lihtsalt pull-requesti tõstma, kolleegid vaatavad muudatused üle ja saab kiiresti trunk'i voolata. Kiiresti? Kuidas siis niimoodi. Paar-kolm sada pom.xml ülevaatusel, ja see ei hõlma koodi. Lisaks ei ole merge-konfliktide eest keegi kaitstud nii paljude muutunud failide puhul. Siin tuleb märkida, et CI protsessis toimuvad versioonimuutused automaatselt koos funktsionaalsuse muutumisega, mitte kuidagi eraldi.
Uued võimalused
Mõneks ajaks rahunesime ja leppisime sellega, et elasime edasi, kuni poisid kaasas mavenisse alates versioonist 3.5.0-beta-1 toe nii nimetatud "versioonide asendajate" (placeholders) jaoks. Asendajate mõte on selles, et pom.xml konkreetselt näidatud projekti versioonide asemel kasutatakse muutujaid ${revision}, ${sha1} ja ${changelist}. Nende omaduste väärtusi saab määrata kas elemendis <properties>, või saab neid määrata läbi süsteemi omaduse
mvn -Drevision=2.0.0 clean package
Süsteemi omaduste väärtused on eelised väärtustele, mis on määratud <properties>.
Vanem
<project>
<modelVersion>4.0.0<\/modelVersion>
<parent>
<groupId>org.apache<\/groupId>
<artifactId>apache<\/artifactId>
<version>18<\/version>
<\/parent>
<groupId>org.apache.maven.ci<\/groupId>
<artifactId>ci-parent<\/artifactId>
<name>Esimene CI Sõbralik<\/name>
<version>${revision}${sha1}${changelist}<\/version>
…
<properties>
<revision>1.3.1<\/revision>
<changelist>Peab olema olemas<\/changelist>
<sha1\/>
<\/properties>
<\/project>
Järeltulija
<project>
<modelVersion>4.0.0<\/modelVersion>
<parent>
<groupId>org.apache.maven.ci<\/groupId>
<artifactId>ci-parent<\/artifactId>
<version>${revision}${sha1}${changelist}<\/version>
<\/parent>
<groupId>org.apache.maven.ci<\/groupId>
<artifactId>ci-child<\/artifactId>
…
<\/project>
Kui soovid luua versiooni 2.0.0-SNAPSHOT, siis kasutame lihtsalt
mvn -Drevision=2.0.0 clean package
Kui soovid teha väljaande, siis lihtsalt nullime SNAPSHOT
mvn -Dchangelist= clean package
*Ülaltoodud näited on võetud Maven Apache Project veebisaidilt
Karm reaalsus
Kõik on hästi ja tore, on aeg tunda rahulolu, kuid ei. Selgub, et installi ja deploy jaoks ei sobi see meetod, kuna publikatsioonide jaoks, mis avaldatakse hoidlas, ei asendata ${revision} selle väärtusega ja maven ei saa edasi aru, millest üldse jutt.
<parent>
<groupId>org.apache<\/groupId>
<artifactId>apache<\/artifactId>
<version>${revision}<\/version>
<\/parent>
Valgus tunneli lõpus
Probleemi lahendust tuleb otsida. Oleks saanud olukorda päästa . See plugin allows all variables in pom, but also cuts out a lot of other information that is only needed during assembly and is not required when importing published artifacts into other projects. The plugin also "flattens" all parent-child dependencies, resulting in flat poms that include everything needed. The inconvenience was that it cuts out too much "extra" content, which was not acceptable to us. After studying the information on the development of this plugin, it turned out that we are not alone in the universe, and back in August 2018, a pull request was created in the plugin's GitHub repository with the request to make it possible to determine how to "distort" pom.xml by ourselves. The developers listened to the voices of the needy, and already in December, with the release of the new version 1.1.0, a new mode resolveCiFriendliesOnly appeared in flatten-maven-plugin, which fit perfectly – it leaves pom.xml as is, except for the element <version> and allows ${revision}, ${sha1} ja ${changelist}.
Add plugin to project
<plugins>
<plugin>
<groupId>org.codehaus.mojo<\/groupId>
<artifactId>flatten-maven-plugin<\/artifactId>
<version>1.1.0<\/version>
<configuration>
<updatePomFile>true<\/updatePomFile>
<flattenMode>resolveCiFriendliesOnly<\/flattenMode>
<\/configuration>
<executions>
<execution>
<id>flatten<\/id>
<phase>process-resources<\/phase>
<goals>
<goal>flatten<\/goal>
<\/goals>
<\/execution>
<execution>
<id>flatten.clean<\/id>
<phase>clean<\/phase>
<goals>
<goal>clean<\/goal>
<\/goals>
<\/execution>
<\/executions>
<\/plugin>
<\/plugins>
Valmis!
Happy ending
From now on, in order to change the version of the entire project and notify all dependencies about this, we only need to edit the <revision> element in just one root pom.xml. Instead of receiving a hundred or so of these files with the same change, we receive just one. This also eliminates the need to use versions-maven-plugin.
Allikas: habr.com
