Пра нас
У 1С мы распрацоўваем не толькі платформу на и , але і прыкладанні на Java – у прыватнасці новае асяроддзе распрацоўкі на базе Eclipse і сервер глыбока інтэграванага з платформай месэнджара - .
Уступленне
У якасці сістэмы зборкі Java-прыкладанняў часцей за ўсё мы выкарыстоўваем maven, і ў гэтым невялікім артыкуле хацелі б расказаць аб адной з праблем, з якой прыйшлося сутыкнуцца ў працэсе арганізацыі распрацоўкі, і аб падыходзе, які дазволіў гэтую праблему пераадолець.
Перадумовы і працоўны працэс
У сувязі са спецыфікай распрацоўкі ў нашых maven-праектах мы выкарыстоўваем дастаткова шмат модуляў, залежнасцяў і даччыных праектаў. Колькасць pom-файлаў у адным дрэве можа вылічацца дзясяткамі і нават сотнямі.
Здавалася б: нічога страшнага, адзін раз стварылі і забыліся. Калі трэба нешта памяняць ці дадаць ва ўсіх файлах адразу, існуе маса зручных прылад у рэдактарах і IDE. А якая самая распаўсюджаная рэгулярная змена pom.xml? Мяркуем, што змена версій праекту і залежнасцяў. Магчыма, нехта захоча з гэтым паспрачацца, але ў нас справа ідзе менавіта так. Чыннік крыецца ў тым, што нараўне з ядром мы раўналежна распрацоўваем шмат уласных бібліятэк, і для сталай узнаўляльнасці вынікаў зборкі і тэставанні выкарыстанне снэпшотаў не ўяўляецца нам зручным падыходам. Па гэтай прычыне і даводзіцца паднімаць нумар версіі ў праектах пры кожнай зборцы.
Таксама ў распрацоўніка час ад часу ўзнікае неабходнасць сабраць сваю галінку якой-небудзь бібліятэкі і праверыць яе працаздольнасць па ўсіх залежнасцях, для чаго ў іх усіх даводзіцца ўручную мяняць версію.
Першапачатковае рашэнне
З такімі частымі і шматлікімі зменамі версій працэс у рамках CI жадаецца спрасціць і аўтаматызаваць. Тут на дапамогу прыходзіць зручная агульнавядомая ўбудова. versions-maven-plugin - падключаем яго і запускаем
mvn -N versions:set -DnewVersion=2.0.1
і мавен усё як трэба зробіць: прабяжыць па іерархіі зверху данізу, усе версіі падменіць - прыгажосць! Цяпер засталося падняць pull-request, калегі змены адгледзяць, і можна хуценька ўлівацца ў trunk. Хуценька? Як бы ня так. Пара-тройка сотняў pom.xml на раўчу, і гэта не лічачы кода. У дадатак і ад merge-канфліктаў ніхто не застрахаваны пры такой вялікай колькасці змененых файлаў. Тут трэба заўважыць, што падчас CI змены версій адбываюцца аўтаматычна разам са зменай функцыянальнасці, а не неяк асобна.
новыя магчымасці
На некаторы час мы супакоіліся і, змірыўшыся, так і жылі, пакуль хлопцы з не ўключылі ў maven, пачынальна з версіі 3.5.0-beta-1, падтрымку так званых "заменнікаў" версій (placeholders). Сутнасць гэтых заменнікаў у тым, што ў pom.xml замест канкрэтнага ўказання версіі праекта выкарыстоўваюцца зменныя ${revision}, ${sha1} и ${changelist}. Самі значэнні гэтых уласцівасцяў задаюцца або ў элеменцеўласцівасці>, альбо іх можна вызначыць праз сістэмную ўласцівасць
mvn -Drevision=2.0.0 clean package
Значэнні сістэмных уласцівасцяў маюць перавагу перад значэннямі, вызначанымі ўўласцівасці>.
бацька
4.0.0
org.apache
apache
18
org.apache.maven.ci
ci-parent
First CI Friendly
${revision}${sha1}${changelist}
...
1.3.1
-SNAPSHOT
Нашчадак
4.0.0
org.apache.maven.ci
ci-parent
${revision}${sha1}${changelist}
org.apache.maven.ci
ci-child
...
Калі жадаецца сабраць версію 2.0.0-SNAPSHOT, то проста выкарыстоўваем
mvn -Drevision=2.0.0 clean package
Калі жадаецца зрабіць рэліз, то проста абнуляем SNAPSHOT
mvn -Dchangelist= clean package
*Прыклады вышэй узяты з на сайце Maven Apache Project
Суровая рэальнасць
Усё добра і выдатна, пара выпрабаваць пачуццё задавальнення, але не. Аказваецца, што для install і deploy гэты спосаб не падыдзе, паколькі ў апісаннях артэфактаў, якія публікуюцца ў рэпазітар, не будзе падмяняцца. ${revision} на яе значэнне і maven далей не зразумее пра што ўвогуле гаворка.
org.apache
apache
${revision}
Святло ў канцы тунэлю
Трэба шукаць вырашэнне праблемы. Сітуацыю мог бы выратаваць . Гэты плягін дазваляе ўсе зменныя ў pom, але заадно выразае масу іншай інфармацыі, якая патрэбна толькі пры зборцы і не патрэбна пры імпарце апублікаваных артэфактаў у іншыя праекты. Таксама плягін «выпроствае» усе parent-child залежнасці, і ў выніку атрымліваюцца плоскія pom, якія ўключаюць у сябе ўсё, што трэба. Нязручнасць заключалася ў тым, што выразае "лішняга" ён занадта шмат, што нас зусім не задавальняла. Пасля вывучэння інфармацыі па распрацоўцы гэтага плагіна, высветлілася, што мы не адны такія ў сусвеце, і яшчэ ў жніўні 2018 на гітхабе ў рэпазітары плагіна быў створаны pull-request з пажаданнем зрабіць магчымасць вызначаць самастойна як трэба "псаваць" pom.xml. Распрацоўнікі прыслухаліся да галасоў якія імкнуцца, і ўжо ў снежні з вынахадам новай версіі 1.1.0 у flatten-maven-plugin з'явіўся новы рэжым resolveCiFriendliesOnly, які як ніколі прыйшоўся якраз - ён пакідае pom.xml як ёсць, акрамя элемента і дазваляе ${revision}, ${sha1} и ${changelist}.
Дадаем плягін у праект
org.codehaus.mojo
flatten-maven-plugin
1.1.0
true
resolveCiFriendliesOnly
flatten
process-resources
flatten
flatten.clean
clean
clean
Гатова!
Хэпі-энд
З гэтага часу нам, каб змяніць версію ўсяго праекта і даць ведаць аб гэтым усім залежнасцям, трэба ўсяго адрэдагаваць элементперагляд> у адным толькі каранёвым pom.xml. На рэўю прылятае не сотня-другая гэтых файлаў з аднолькавай зменай, а адзін. Ну і адпадае неабходнасць у выкарыстанні versions-maven-plugin.
Крыніца: habr.com