🥇Erfahrungen mit dem flatten-maven-plugin zur Vereinfachung der Versionierung in Maven-Projekten

Über uns

Bei 1C entwickeln wir nicht nur die Plattform 1C: Enterprise findet man C++ und JavaScript, sondern auch Anwendungen in Java – insbesondere eine neue Entwicklungsumgebung Enterprise Development Tools basierend auf Eclipse, und der Server ist tief in die Plattform des Messengers integriert – Interaktionssysteme.

Einleitung

Als Build-System für Java-Anwendungen verwenden wir häufig Maven, und in diesem kurzen Artikel möchten wir über eines der Probleme sprechen, mit denen wir bei der Organisation der Entwicklung konfrontiert waren, sowie über den Ansatz, der uns geholfen hat, dieses Problem zu überwinden.

Voraussetzungen und Arbeitsablauf

Aufgrund der Besonderheiten der Entwicklung in unseren Maven-Projekten verwenden wir recht viele Module, Abhängigkeiten und Unterprojekte. Die Anzahl der POM-Dateien in einem Baum kann sich auf Dutzende oder sogar Hunderte belaufen.

Es scheint, als wäre es nicht schlimm, einmal erstellt und dann vergessen. Wenn man etwas in allen Dateien gleichzeitig ändern oder hinzufügen möchte, gibt es viele nützliche Werkzeuge in Editoren und IDEs. Was ist die häufigste Veränderung der pom.xml? Wir gehen davon aus, dass es sich um die Änderung der Versionen des Projekts und der Abhängigkeiten handelt. Vielleicht möchte jemand dem widersprechen, aber so ist es bei uns. Der Grund liegt darin, dass wir neben dem Kern viele eigene Bibliotheken parallel entwickeln, und für eine konsistente Reproduzierbarkeit der Build- und Testergebnisse ist die Verwendung von Snapshots für uns kein praktischer Ansatz. Deshalb müssen wir die Versionsnummer in den Projekten bei jedem Build erhöhen.

Auch der Entwickler benötigt von Zeit zu Zeit die Möglichkeit, seinen Zweig einer Bibliothek zu erstellen und dessen Funktionsfähigkeit in Bezug auf alle Abhängigkeiten zu überprüfen, was erfordert, dass in allen manuell die Version geändert werden muss.

Ursprüngliche Lösung

Mit so häufigen und zahlreichen Versionsänderungen möchte man den Prozess im CI-Bereich vereinfachen und automatisieren. Hier kommt ein nützliches, weithin bekanntes Plugin ins Spiel. versions-maven-plugin — wir integrieren es und starten es

mvn -N versions:set -DnewVersion=2.0.1

und Maven erledigt alles wie gewünscht: es durchläuft die Hierarchie von oben nach unten und ersetzt alle Versionen — wunderbar! Jetzt bleibt nur noch, einen Pull-Request zu erstellen, den die Kollegen überprüfen werden, und dann können wir schnell in den Trunk einfließen. Schnell? So einfach ist das nicht. Da sind ein paar hundert pom.xml zur Überprüfung, und das ist noch nicht alles. Zudem sind wir bei so vielen geänderten Dateien nicht vor Merge-Konflikten gefeit. Hier muss man anmerken, dass die Versionsänderungen im CI-Prozess automatisch erfolgen, zusammen mit den Änderungen im Funktionsumfang und nicht separat.

Neue Funktionen

Wir haben eine Zeit lang Ruhe gefunden und, bis wir uns beruhigt haben, so gelebt, bis die Leute von Maven Apache Project in Maven ab Version 3.5.0-beta-1 die Unterstützung für sogenannte „Versionsplatzhalter“ (placeholders) integriert haben. Die Idee dieser Platzhalter ist, dass an pom.xml stelle der konkreten Versionsangabe Variablen verwendet werden ${revision}, ${sha1} und ${changelist}. Die Werte dieser Eigenschaften werden entweder im Element <properties> festgelegt oder sie können über eine Systemvariable definiert werden

mvn -Drevision=2.0.0 clean package

Systemeigenschaften haben Vorrang vor den in <properties> definierten Werten.

Elternteil
<project>
  4.0.0
  <parent>
    org.apache
    apache
    18
  </parent>
  org.apache.maven.ci
  ci-parent
  Erstes CI-freundliches Projekt
  <version>${revision}${sha1}${changelist}</version>
  …
  <properties>
    <revision>1.3.1</revision>
    <changelist>-SNAPSHOT</changelist>
    <sha1/>
  </properties>
</project>

Nachkomme
<project>
  4.0.0
  <parent>
    org.apache.maven.ci
    ci-parent
    <version>${revision}${sha1}${changelist}</version>
  </parent>
  org.apache.maven.ci
  ci-child
   …
</project>

Wenn Sie die Version 2.0.0-SNAPSHOT bauen möchten, verwenden Sie einfach

mvn -Drevision=2.0.0 clean package

Wenn Sie ein Release machen wollen, setzen Sie einfach SNAPSHOT zurück

mvn -Dchangelist= clean package

*Die obigen Beispiele stammen von einem Artikel der Apache Maven-Projektwebsite

Die harte Realität

Alles ist gut und schön, es ist Zeit, ein Gefühl der Zufriedenheit zu erleben, aber nein. Es stellt sich heraus, dass dieser Weg für install und deploy nicht geeignet ist, da in den Beschreibungen der in das Repository veröffentlichten Artefakte nicht ${revision} durch ihren Wert ersetzt wird und Maven somit nicht verstehen kann, worum es überhaupt geht.

<parent>
    org.apache
    apache
    ${revision}
</parent>

Licht am Ende des Tunnels

Es gilt, eine Lösung für das Problem zu finden. Die Situation könnte durch flatten-maven-plugin. Dieses Plugin erlaubt es, alle Variablen im POM zu verwenden, schneidet jedoch auch eine Menge anderer Informationen heraus, die nur für den Build benötigt werden und beim Import veröffentlichter Artefakte in andere Projekte nicht nötig sind. Das Plugin "glättet" alle Parent-Child-Abhängigkeiten, und am Ende erhält man flache POMs, die alles enthalten, was man benötigt. Das Unbehagen resultierte daraus, dass es zu viel „Überflüssiges“ entfernt, was für uns völlig unakzeptabel war. Nach eingehender Recherche zur Entwicklung dieses Plugins stellte sich heraus, dass wir nicht die Einzigen im Universum sind. Bereits im August 2018 wurde im GitHub-Repository des Plugins ein Pull-Request erstellt mit dem Wunsch, die Möglichkeit zu schaffen, selbst zu bestimmen, wie man das pom.xml „verändern“ möchte. Die Entwickler hörten auf die Stimmen der Bedürftigen, und bereits im Dezember mit der Veröffentlichung der neuen Version 1.1.0 erhielt das flatten-maven-plugin einen neuen Modus resolveCiFriendliesOnly, der wie gerufen kam – er lässt das pom.xml unverändert, außer beim Element <version> und erlaubt ${revision}, ${sha1} und ${changelist}.

Fügen Sie das Plugin zum Projekt hinzu

<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>
        flatten
        process-resources
        <goals>
          flatten
        </goals>
      </execution>
      <execution>
        flatten.clean
        clean
        <goals>
          clean
        </goals>
      </execution>
    </executions>
  </plugin>
</plugins>

Fertig!

Happy end

Um die Version des gesamten Projekts zu ändern und alle Abhängigkeiten darüber zu informieren, müssen wir nur das Element <revision> in einem einzigen Wurzelverzeichnis bearbeiten. Anstatt hunderte solcher Dateien mit identischen Änderungen zu erhalten, kommt nur eine. Dadurch entfällt auch die Notwendigkeit für pom.xml. На ревью прилетает не сотня-другая этих файлов с одинаковым изменением, а один. Ну и отпадает необходимость в использовании versions-maven-plugin.

Quelle: habr.com