o nás
V 1C vyvíjame nielen platformu
Vstup
Maven najčastejšie používame ako zostavovací systém pre Java aplikácie a v tomto krátkom článku by sme chceli hovoriť o jednom z problémov, ktorým sme museli čeliť v procese organizácie vývoja, a o prístupe, ktorý nám umožnil tento problém prekonať. problém.
Predpoklady a pracovný postup
Vzhľadom na špecifiká vývoja v našich maven projektoch používame pomerne veľa modulov, závislostí a detských projektov. Počet súborov pom v jednom strome môže byť v desiatkach alebo dokonca stovkách.
Zdalo by sa: žiadny veľký problém, raz to vytvorili a zabudli na to. Ak potrebujete zmeniť alebo pridať niečo vo všetkých súboroch naraz, v editoroch a IDE je veľa pohodlných nástrojov. Aká je najbežnejšia pravidelná zmena na pom.xml? Veríme, že zmeny vo verziách projektu a závislosti. Možno s tým bude chcieť niekto polemizovať, ale presne taká je situácia u nás. Dôvod spočíva v tom, že spolu s jadrom súčasne vyvíjame množstvo vlastných knižníc a pre neustálu reprodukovateľnosť výsledkov zostavovania a testovania sa nám používanie snímok nezdá ako vhodný prístup. Z tohto dôvodu je potrebné pri každej zostave zvýšiť číslo verzie v projektoch.
Vývojár si tiež z času na čas potrebuje vybudovať vlastnú vetvu knižnice a skontrolovať jej funkčnosť voči všetkým závislostiam, pre ktoré musí manuálne meniť verziu všetkých.
Počiatočné riešenie
Pri takýchto častých a viacnásobných zmenách verzií chcem zjednodušiť a zautomatizovať proces v rámci CI. Tu prichádza na pomoc pohodlný, dobre známy doplnok. verzie-maven-plugin - pripojte ho a spustite ho
mvn -N version:set -DnewVersion=2.0.1
a Maven urobí všetko tak, ako má: prebehne hierarchiou zhora nadol a nahradí všetky verzie – krása! Teraz už len zostáva vzniesť požiadavku na stiahnutie, kolegovia skontrolujú zmeny a vy sa môžete rýchlo pripojiť k kufru. rýchlo? Bez ohľadu na to, ako to je. Pár stoviek pom.xml na kontrolu, a to nepočíta kód. Navyše nikto nie je v bezpečí pred konfliktmi pri zlučovaní s takým veľkým počtom zmenených súborov. Tu je potrebné poznamenať, že v procese CI sa zmeny verzie vyskytujú automaticky spolu so zmenami funkčnosti, a nie nejako oddelene.
Nové funkcie
Na chvíľu sme sa ukľudnili a rezignujúc sme tak žili až do chlapov z
mvn -Drevision=2.0.0 čistý balík
Hodnoty systémových vlastností majú prednosť pred hodnotami definovanými vvlastnosti>.
Rodič
4.0.0
org.apache
apache
18
org.apache.maven.ci
ci-rodič
Prvý CI Friendly
${revision}${sha1}${changelist}
...
1.3.1
-SNÍMKA
Potomok
4.0.0
org.apache.maven.ci
ci-rodič
${revision}${sha1}${changelist}
org.apache.maven.ci
ci-dieťa
...
Ak chcete zostaviť verziu 2.0.0-SNAPSHOT, stačí použiť
mvn -Drevision=2.0.0 čistý balík
Ak chcete urobiť vydanie, stačí resetovať SNAPSHOT
mvn -Dchangelist= čistý balík
*Vyššie uvedené príklady sú prevzaté z
Tvrdá realita
Všetko je dobré a zdravé, je čas pocítiť pocit zadosťučinenia, ale nie. Ukazuje sa, že táto metóda nebude fungovať pri inštalácii a nasadení, pretože nebude nahradená v popisoch artefaktov zverejnených v úložisku ${revision} na jeho význame a majster už nepochopí, o čo ide.
org.apache
apache
${revision}
Svetlo na konci tunela
Musíme hľadať riešenie problému. Mohol zachrániť situáciu
Pridanie doplnku do projektu
org.codehaus.mojo
flatten-maven-plugin
1.1.0
pravda
resolveCiFriendliesOnly
sploštiť
proces-zdroje
sploštiť
sploštiť.čistý
čisté
čisté
Hotovo!
Šťastný koniec
Odteraz, aby sme zmenili verziu celého projektu a dali o nej vedieť všetkým závislostiam, stačí upraviť prvokrevízia> len v koreni pom.xml. Na recenziu nepríde sto alebo dva týchto súborov s rovnakou zmenou, ale jeden. No nie je potrebné používať verzie-maven-plugin.
Zdroj: hab.com