Erfahrung mit dem Flatten-Maven-Plugin zur Vereinfachung der Versionierung in Maven-Projekten

Über uns

In 1C entwickeln wir nicht nur die 1C: Enterprise- Plattform in C ++ und JavaScript , sondern auch Java-Anwendungen - insbesondere die neue Eclipse-basierte Entwicklungsumgebung für Enterprise Development Tools und einen Server, der tief in die Messenger-Plattform integriert ist - Interaction Systems .

Eintrag

In den meisten Fällen verwenden wir Maven als System zum Zusammenstellen von Java-Anwendungen. In diesem kurzen Artikel möchten wir auf eines der Probleme eingehen, mit denen wir uns während des Entwicklungsprozesses befassen mussten, und auf den Ansatz, mit dem wir dieses Problem lösen konnten.

Hintergrund und Workflow

Aufgrund der Besonderheiten der Entwicklung in unseren Maven-Projekten verwenden wir viele Module, Abhängigkeiten und untergeordnete Projekte. Die Anzahl der POM-Dateien in einem Baum kann zehn oder sogar Hunderte betragen.



Es scheint: Es ist in Ordnung, wenn es einmal erstellt und vergessen wurde. Wenn Sie in allen Dateien gleichzeitig etwas ändern oder hinzufügen müssen, gibt es in Editoren und IDEs viele praktische Tools. Und was ist die häufigste regelmäßige Änderung an pom.xml? Wir glauben, dass sich Projektversionen und -abhängigkeiten ändern. Vielleicht möchte jemand damit streiten, aber das ist bei uns der Fall. Der Grund dafür ist, dass wir zusammen mit dem Kernel gleichzeitig viele unserer eigenen Bibliotheken entwickeln. Für die ständige Reproduzierbarkeit der Assemblierungs- und Testergebnisse erscheint uns die Verwendung von Snapshots nicht als praktischer Ansatz. Aus diesem Grund ist es erforderlich, die Versionsnummer in den Projekten bei jeder Baugruppe zu erhöhen.

Außerdem muss der Entwickler von Zeit zu Zeit seinen eigenen Zweig einer Bibliothek sammeln und deren Leistung anhand aller Abhängigkeiten überprüfen, für die alle die Version manuell ändern müssen.

Erste Entscheidung

Mit solch häufigen und mehrfachen Versionsänderungen möchte der Prozess innerhalb von CI vereinfacht und automatisiert werden. Hier hilft das praktische bekannte Version-Maven-Plugin-Plugin - wir stecken es ein und führen es aus

mvn -N Versionen: setze -DnewVersion = 2.0.1

und der Maven wird alles tun, wie er sollte: durch die Hierarchie von oben nach unten laufen, alle Versionen ersetzen - Schönheit! Jetzt muss die Pull-Anfrage noch ausgelöst werden, die Kollegen werden die Änderungen beobachten und Sie können sich schnell dem Trunk anschließen. Schnell? Egal wie. Ein paar Hundert von pom.xml pro Überprüfung, und das zählt den Code nicht. Darüber hinaus ist niemand vor Zusammenführungskonflikten mit einer so großen Anzahl geänderter Dateien sicher. Hierbei ist zu beachten, dass während des CI-Prozesses Versionsänderungen automatisch zusammen mit einer Änderung der Funktionalität auftreten und nicht irgendwie separat.

Neue Funktionen

Für eine Weile beruhigten wir uns und lebten in Frieden, bis die Jungs vom Maven Apache Project, die in maven enthalten waren, ab Version 3.5.0-beta-1 die sogenannten "Platzhalter" von Versionen (Platzhalter) unterstützten. Das Wesentliche dieser Substitute ist, dass pom.xml die Variablen $ {revision} , $ {sha1} und $ {changelist} verwendet, anstatt die Projektversion anzugeben. Die Werte dieser Eigenschaften selbst werden entweder im Element < Eigenschaften > festgelegt oder können über die Systemeigenschaft definiert werden

mvn -Drevision = 2.0.0 sauberes Paket

Systemeigenschaftswerte haben Vorrang vor den in < Eigenschaften > definierten Werten.

Der Elternteil
<Projekt>
<modelVersion> 4.0.0 </ modelVersion>
<Eltern>
<groupId> org.apache </ groupId>
<artifactId> Apache </ifactId>
<Version> 18 </ Version>
</ parent>
<groupId> org.apache.maven.ci </ groupId>
<artifactId> ci-parent </ifactId>
<name> First CI Friendly </ name>
<version> $ {revision} $ {sha1} $ {changelist} </ version>
...
<Eigenschaften>
<revision> 1.3.1 </ revision>
<changelist> -SNAPSHOT </ changelist>
<sha1 />
</ property>
</ project>

Nachkomme
<Projekt>
<modelVersion> 4.0.0 </ modelVersion>
<Eltern>
<groupId> org.apache.maven.ci </ groupId>
<artifactId> ci-parent </ifactId>
<version> $ {revision} $ {sha1} $ {changelist} </ version>
</ parent>
<groupId> org.apache.maven.ci </ groupId>
<artifactId> ci-child </ifactId>
...
</ project>


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

mvn -Drevision = 2.0.0 sauberes Paket

Wenn Sie eine Veröffentlichung machen möchten, setzen Sie SNAPSHOT einfach auf Null

mvn -Dchangelist = sauberes Paket

* Die obigen Beispiele stammen aus einem Artikel auf der Maven Apache Project-Website

Harte Realität

Alles ist gut und gesund, es ist Zeit, ein Gefühl der Zufriedenheit zu erleben, aber nein. Es stellt sich heraus, dass diese Methode für die Installation und Bereitstellung nicht funktioniert, da $ {revision} nicht durch seinen Wert in den Beschreibungen der im Repository veröffentlichten Artefakte ersetzt wird und maven nicht versteht, worum es geht.

<Eltern>
<groupId> org.apache </ groupId>
<artifactId> Apache </ifactId>
<version> $ {revision} </ version>
</ parent>

Licht am Ende des Tunnels

Wir müssen nach einer Lösung für das Problem suchen. Die Situation hätte durch ein Flatten-Maven-Plugin gerettet werden können. Dieses Plugin erlaubt alle Variablen in pom, schneidet aber gleichzeitig eine Menge anderer Informationen aus, die nur während der Montage benötigt werden und beim Importieren veröffentlichter Artefakte in andere Projekte nicht benötigt werden. Außerdem „glättet“ das Plugin alle Eltern-Kind-Abhängigkeiten, und als Ergebnis erhalten wir Flat Pom, das alles enthält, was Sie brauchen. Die Unannehmlichkeit war, dass er "zu viel" zu viel herausschneidet, was uns überhaupt nicht zusagte. Nachdem wir die Informationen zur Entwicklung dieses Plugins studiert hatten, stellte sich heraus, dass wir nicht die einzigen im Universum sind. Bereits im August 2018 wurde auf dem Github im Plugin-Repository eine Pull-Anfrage erstellt, um unabhängig bestimmen zu können, wie pom.xml „verwöhnt“ werden soll. Die Entwickler hörten den Stimmen der Betroffenen zu und bereits im Dezember erschien mit der Veröffentlichung der neuen Version 1.1.0 ein neuer ResolutionCiFriendliesOnly-Modus im Flatten-Maven-Plugin, der wie nie zuvor pom.xml so lässt, wie er ist, mit Ausnahme des <version> -Elements und $ {revision} , $ {sha1} und $ {changelist} .

Fügen Sie dem Projekt ein Plugin hinzu

<plugins>
<plugin>
<groupId> org.codehaus.mojo </ groupId>
<artifactId> flatten-maven-plugin </ifactId>
<Version> 1.1.0 </ Version>
<Konfiguration>
<updatePomFile> true </ updatePomFile>
<flattenMode> resolveCiFriendliesOnly </ flatMode>
</ configuration>
<Ausführungen>
<Ausführung>
<id> abflachen </ id>
<phase> Prozessressourcen </ Phase>
<Ziele>
<Ziel> abflachen </ Ziel>
</ Ziele>
</ Ausführung>
<Ausführung>
<id> flatten.clean </ id>
<Phase> sauber </ Phase>
<Ziele>
<Ziel> sauber </ Ziel>
</ Ziele>
</ Ausführung>
</ Ausführungen>
</ plugin>
</ plugins>


Fertig!

Happy End

Um die Version des gesamten Projekts zu ändern und alle Abhängigkeiten darüber zu informieren, müssen wir von nun an nur noch das < revision > -Element in nur einer Root- Datei pom.xml bearbeiten. Es sind nicht hundert oder zwei dieser Dateien mit derselben Änderung, die in die Überprüfung einfließen, sondern eine. Nun, es ist nicht nötig, das Versions-Maven-Plugin zu verwenden .