Про нас
У 1С ми розробляємо не лише платформу на и , а й програми на Java – зокрема нове середовище розробки на базі Eclipse та сервер глибоко інтегрованого з платформою месенджера – .
Вступ
Як система складання Java-додатків найчастіше ми використовуємо maven, і в цій невеликій статті хотіли б розповісти про одну з проблем, з якою довелося зіткнутися в процесі організації розробки, і про підхід, що дозволив цю проблему подолати.
Передумови та робочий процес
У зв'язку зі специфікою розробки у наших maven-проектах ми використовуємо досить багато модулів, залежностей та дочірніх проектів. Кількість pom-файлів в одному дереві може обчислюватись десятками і навіть сотнями.
Здавалося б: нічого страшного, одного разу створили та забули. Якщо треба щось змінити або додати у всіх файлах відразу, існує безліч зручних інструментів у редакторах та IDE. А яка найпоширеніша регулярна зміна pom.xml? Вважаємо, що зміна версій проекту та залежностей. Можливо, хтось захоче з цим посперечатися, але у нас справа саме так. Причина полягає в тому, що поряд з ядром ми паралельно розробляємо багато власних бібліотек, і для постійної відтворюваності результатів складання та тестування використання снепшотів не є зручним підходом. Тому й доводиться піднімати номер версії в проектах при кожній збірці.
Також у розробника іноді виникає необхідність зібрати свою гілку будь-якої бібліотеки і перевірити її працездатність за всіма залежностями, для чого в них усіх доводиться вручну змінювати версію.
Початкове рішення
З такими частими та множинними змінами версій процес у рамках CI хочеться спростити та автоматизувати. Тут на допомогу приходить зручний загальновідомий плагін версії-maven-плагін - Підключаємо його і запускаємо
mvn -N versions:set -DnewVersion=2.0.1
і мавен все як треба зробить: пробіжить ієрархією зверху до низу, всі версії підмінить - краса! Тепер залишилося підняти pull-request, колеги зміни подивляться, і можна швиденько вливатись у trunk. Швиденько? Як би не так. Пара-трійка сотень пом.хмл на рев'ю, і це не рахуючи коду. До того ж від merge-конфліктів ніхто не застрахований за такої великої кількості змінених файлів. Тут слід зазначити, що у процесі CI зміни версій відбуваються автоматично разом із зміною функціональності, а чи не якось окремо.
Нові можливості
На деякий час ми заспокоїлися і, змирившись, так і жили, поки хлопці з не включили в maven, починаючи з версії 3.5.0-beta-1 підтримку так званих «замінників» версій (placeholders). Суть цих замінників у тому, що в пом.хмл замість конкретної вказівки версії проекту використовуються змінні ${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
Готово!
Щасливий кінець
Відтепер нам, щоб змінити версію всього проекту і дати знати про це всім залежностям, треба лише відредагувати елементперегляд> в одному лише кореневому пом.хмл. На реву прилітає не сотня-друга цих файлів з однаковою зміною, а один. Ну і відпадає потреба у використанні версії-maven-плагін.
Джерело: habr.com