🥇Опит с използването на flatten-maven-plugin за опростяване на версионирането в maven-проекти

За нас

В 1С ние разработваме не само платформа 1С: Предприятие на C++ и JavaScript, но и приложения на 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 в преглед, и това не включва кода. Освен това никой не е застрахован от конфликти при обединение при толкова много изменени файлове. Тук трябва да се отбележи, че в процеса на CI промените на версиите се случват автоматично заедно с промените във функционалността, а не отделно.

Нови възможности

Няколко време се успокоявахме и, примирявайки се, така и живеехме, докато момчетата от Maven Apache Project не добавиха в maven, започвайки от версия 3.5.0-beta-1, поддръжка на така наречените „заместители“ на версии (placeholders). Същността на тези заместители е, че pom.xml вместо конкретно указание на версията на проекта се използват променливи ${revision}, ${sha1} и ${changelist}. Самите стойности на тези свойства се определят или в елемента <properties>, или могат да бъдат определени чрез системно свойство

mvn -Drevision=2.0.0 clean package

Стойностите на системните свойства имат предимство пред стойностите, определени в <properties>.

Родител
<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>Първи CI приятелски<\/name>
  <version>${revision}${sha1}${changelist}<\/version>
  …
  <properties>
    <revision>1.3.1<\/revision>
    <changelist>-SNAPSHOT<\/changelist>
    <sha1\/>
  <\/properties>
<\/project>

Потенок
<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>

Ако искате да съберете версия 2.0.0-SNAPSHOT, просто използвайте

mvn -Drevision=2.0.0 clean package

Ако искате да направите издание, просто нулирайте SNAPSHOT

mvn -Dchangelist= clean package

*Примерите по-горе са взети от на статията на сайта Maven Apache Project

Сурова реалност

Всичко е добре и чудесно, време е да усетим удовлетворение, но не. Оказва се, че този метод няма да проработи за install и deploy, тъй като в описанията на артефактите, публикувани в репозитория, стойността му няма да се замества ${revision} и maven няма да разбере за какво става въпрос.

<parent>
    <groupId>org.apache<\/groupId>
    <artifactId>apache<\/artifactId>
    <version>${revision}<\/version>
<\/parent>

Светлина в края на тунела

Трябва да търсим решение на проблема. Ситуацията можеше да бъде спасена от flatten-maven-plugin. Този плъгин разрешава всички променливи в pom, но също така отстранява много друга информация, която е необходима само по време на компилация и не е нужна при импортиране на публикувани артефакти в други проекти. Освен това, плъгинът „изправя“ всички parent-child зависимости, и в крайна сметка получаваме плоски pom, които включват всичко необходимо. Неудобството беше, че той отстранява твърде много „излишни“ данни, което не ни удовлетворяваше. След проучване на информацията за разработката на този плъгин, разбрахме, че не сме сами във вселената, и още през август 2018 в репозитория на плъгина в GitHub бе създаден pull-request с желание да се направи възможно да определяме сами как да „повредим“ pom.xml. Разработчиците се вслушаха в гласовете на нуждаещите се и вече през декември с излизането на нова версия 1.1.0 в flatten-maven-plugin се появи нов режим resolveCiFriendliesOnly, който бе точно на място – той оставя pom.xml такъв, какъвто е, освен елемента <version> и разрешава ${revision}, ${sha1} и ${changelist}.

Добавяме плъгина в проекта

<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>

Готово!

Ш Happy end

Отсега нататък, за да променим версията на целия проект и да уведомим за това всички зависимости, трябва само да редактираме елемента <revision> в единствено кореновия pom.xml. На рецензията получаваме не стотици от тези файлове с идентични изменения, а един. Също така отпада необходимостта от използване versions-maven-plugin.

Източник: habr.com