Alconost ist professionell tätig
Bei 1C entwickeln wir nicht nur die Plattform auf und , sondern auch Anwendungen in Java – insbesondere eine neue Entwicklungsumgebung basierend auf Eclipse und einem tief in die Plattform integrierten Server des Messengers – .
Einleitung
Als Build-System für Java-Anwendungen verwenden wir häufig Maven. In diesem kleinen Artikel möchten wir über eines der Probleme sprechen, mit denen wir bei der Organisation der Entwicklung konfrontiert waren, und über den Ansatz, der uns geholfen hat, dieses Problem zu lösen.
Voraussetzungen und Arbeitsablauf
Aufgrund der spezifischen Art der Entwicklung in unseren Maven-Projekten verwenden wir relativ viele Module, Abhängigkeiten und Unterprojekte. Die Anzahl der pom-Dateien in einem Baum kann sich auf Dutzende oder sogar Hunderte belaufen.
Es scheint harmlos zu sein: Einmal erzeugt und vergessen. Wenn man etwas ändern oder in allen Dateien gleichzeitig hinzufügen muss, gibt es viele praktische Werkzeuge in Editoren und IDEs. Aber was ist die häufigste regelmäßige Änderung in pom.xml? Wir vermuten, dass es sich um die Versionsänderungen von Projekten und Abhängigkeiten handelt. Vielleicht möchte jemand dagegen argumentieren, aber bei uns ist das tatsächlich so. Der Grund dafür liegt darin, dass wir parallel zum Kern viele eigene Bibliotheken entwickeln und die ständige Reproduzierbarkeit der Build- und Testergebnisse einen Ansatz mit Snapshots für uns unpraktisch macht. Aus diesem Grund müssen wir bei jedem Build die Versionsnummer der Projekte erhöhen.
Auch der Entwickler hat von Zeit zu Zeit die Notwendigkeit, seinen Branch einer bestimmten Bibliothek zu erstellen und deren Funktionalität in Bezug auf alle Abhängigkeiten zu überprüfen, was bedeutet, dass er manuell die Version in allen diesen Abhängigkeiten ändern muss.
Ursprüngliche Lösung
Bei so häufigen und zahlreichen Versionsänderungen möchte man den Prozess im CI vereinfachen und automatisieren. Hier kommt ein praktisches, allgemein bekanntes Plugin zur Hilfe versions-maven-plugin – wir fügen es hinzu und starten
mvn -N versions:set -DnewVersion=2.0.1
und Maven wird alles richtig machen: Es wird die Hierarchie von oben nach unten durchlaufen und alle Versionen ersetzen – wunderbar! Jetzt bleibt nur noch, einen Pull-Request zu erstellen, die Kollegen werden die Änderungen prüfen und man kann schnell in den Trunk einfließen. Schnell? Wie gesagt, zwei bis drei Hundert pom.xml in der Überprüfung, und das ist nicht einmal der Code. Außerdem ist niemand vor Merge-Konflikten gefeit, wenn so viele Dateien geändert wurden. Hier muss angemerkt werden, dass im CI-Prozess Versionsänderungen automatisch zusammen mit der Änderung der Funktionalität stattfinden und nicht separat.
Neue Funktionen
Für eine Weile beruhigten wir uns und lebten so, bis die Jungs von ab Version 3.5.0-beta-1 die Unterstützung für sogenannte "Platzhalter" in Maven einfügten. Das Wesen dieser Platzhalter besteht darin, dass anstelle einer spezifischen Angabe der Projektversion Variablen verwendet werden, pom.xml anstatt konkret die Projektversion anzugeben. ${revision}, ${sha1} und ${changelist}. Die Werte dieser Eigenschaften werden entweder im Element <properties>, oder sie können über eine Systemvariable definiert werden.
mvn -Drevision=2.0.0 clean package
Die Werte der Systemvariablen haben Vorrang vor den Werten, die im <properties>, definiert sind.
Elternteil
<project>
4.0.0
<parent>
org.apache
apache
18
</parent>
org.apache.maven.ci
ci-parent
First CI Friendly
<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 erstellen möchten, verwenden Sie einfach
mvn -Drevision=2.0.0 clean package
Wenn Sie ein Release machen möchten, setzen Sie einfach die SNAPSHOT zurück.
mvn -Dchangelist= clean package
*Die obigen Beispiele stammen von der Website des Maven Apache Project
Die harte Realität
Alles ist gut und schön, es ist Zeit, Zufriedenheit zu empfinden, aber nein. Es stellt sich heraus, dass diese Methode für Install und Deploy nicht geeignet ist, da die Beschreibungen der Artefakte, die im Repository veröffentlicht werden, nicht durch ${revision} ihren Wert ersetzt werden und maven damit nicht versteht, worum es überhaupt geht.
<parent>
org.apache
apache
${revision}
</parent>
Licht am Ende des Tunnels
Es muss eine Lösung für das Problem gefunden werden. Die Situation könnte durch . Dieses Plugin erlaubt alle Variablen in pom, schneidet jedoch gleichzeitig eine Menge anderer Informationen heraus, die nur beim Build benötigt werden und beim Import veröffentlichter Artefakte in andere Projekte nicht erforderlich sind. Außerdem "glättet" das Plugin alle parent-child Abhängigkeiten, und am Ende erhält man flache pom-Dateien, die alles enthalten, was benötigt wird. Das Problem war, dass es zu viel "Überflüssiges" herausgeschnitten hat, was uns ganz und gar nicht passte. Nach dem Studium der Informationen zur Entwicklung dieses Plugins stellte sich heraus, dass wir nicht die einzigen sind, und bereits im August 2018 wurde im GitHub-Repository des Plugins ein Pull-Request erstellt, in dem der Wunsch geäußert wurde, die Möglichkeit zu schaffen, selbst zu bestimmen, wie man pom.xml "verderben" muss. Die Entwickler hörten auf die Stimmen der Bedürfnisartigen, und bereits im Dezember mit der Veröffentlichung der neuen Version 1.1.0 erschien im flatten-maven-plugin ein neuer Modus resolveCiFriendliesOnly, der passender ist als je zuvor – er belässt pom.xml so wie sie ist, mit Ausnahme des Elements <version> und erlaubt ${revision}, ${sha1} und ${changelist}.
Plugin zum Projekt hinzufügen
<plugins>
<plugin>
org.codehaus.mojo
flatten-maven-plugin
1.1.0
<configuration>
true
<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
Von nun an müssen wir nur noch das Element <revision> im einzigen Wurzel pom.xml. Bei der Überprüfung kommt nicht hundert oder mehr dieser Dateien mit der gleichen Änderung an, sondern nur eine. Somit entfällt die Notwendigkeit zur Verwendung von versions-maven-plugin.
Quelle: habr.com
