Alconost is professioneel bezig met
Bij 1C ontwikkelen we niet alleen een platform en een werkende opdracht krijgen. en , maar ook applicaties in Java – met name een nieuwe ontwikkelomgeving gebaseerd op Eclipse en de server die diep geïntegreerd is met het platform van de messenger – .
Inleiding
Als bouwsysteem voor Java-applicaties gebruiken we meestal Maven, en in dit korte artikel willen we het hebben over een van de problemen waarmee we tijdens de ontwikkeling zijn geconfronteerd, en de aanpak die ons heeft geholpen dit probleem op te lossen.
Achtergronden en werkproces
Gezien de specificiteit van de ontwikkeling in onze Maven-projecten gebruiken we behoorlijk veel modules, afhankelijkheden en subprojecten. Het aantal POM-bestanden in één boom kan oplopen tot tientallen of zelfs honderden.
Het lijkt misschien: maak het één keer aan en vergeet het. Als je iets moet wijzigen of toevoegen in alle bestanden, zijn er genoeg handige tools in editors en IDE's. En wat is de meest voorkomende regelmatige wijziging in pom.xml? We vermoeden dat het de wijziging van versies van projecten en afhankelijkheden is. Misschien wil iemand hiertegen in discussie gaan, maar zo vergaat het ons. De reden is dat we naast de kern gelijktijdig veel eigen bibliotheken ontwikkelen, en voor constante reproduceerbaarheid van de bouw- en testresultaten is het gebruik van snapshots voor ons geen handige aanpak. Daarom moeten we bij elke build het versienummer in de projecten verhogen.
Ook heeft de ontwikkelaar af en toe de behoefte om zijn eigen tak van een bibliotheek te bouwen en de functionaliteit ervan te controleren over alle afhankelijkheden, waarvoor we handmatig de versie in al deze afhankelijkheden moeten wijzigen.
Oorspronkelijke oplossing
Met zulke frequente en meervoudige wijzigingen in versies willen we het proces binnen CI vereenvoudigen en automatiseren. Hier komt een handige bekende plugin van pas versions-maven-plugin – we koppelen deze aan en starten
mvn -N versions:set -DnewVersion=2.0.1
en Maven doet alles zoals het hoort: het doorloopt de hiërarchie van boven naar beneden, vervangt alle versies – prachtig! Nu hoeven we alleen nog een pull-request aan te maken, de collega's bekijken de wijzigingen en we kunnen snel in de trunk integreren. Snel? Hoe zou dat kunnen. Een paar honderd pom.xml bij de review, en dat is nog niet eens de code meegerekend. Daarnaast zijn merge-conflicten ook niet te vermijden met zo'n groot aantal wijzigingen in bestanden. Het is belangrijk op te merken dat tijdens het CI-proces versiewijzigingen automatisch plaatsvinden samen met de functionaliteitswijzigingen, en niet afzonderlijk.
Nieuwe mogelijkheden
Een tijdje hebben we het rustig gehouden en ons eraan overgegeven, totdat de jongens van begonnen met het opnemen van ondersteuning voor zogenaamde "plaatsvervangers" van versies (placeholders) in Maven, te beginnen met versie 3.5.0-beta-1. De essentie van deze plaatsvervangers is dat in pom.xml plaats van een specifieke versie van het project variabelen worden gebruikt ${revision}, ${sha1} en ${changelist}. De waarden van deze eigenschappen worden ofwel gedefinieerd in het element <properties>, of ze kunnen worden gedefinieerd via een systeemkenmerk
mvn -Drevision=2.0.0 clean package
Waarden van systeemkenmerken hebben voorrang boven waarden die in <properties> zijn gedefinieerd.
Ouder
<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>Eerste CI-vriendelijk<\/name>
<version>${revision}${sha1}${changelist}<\/version>
…
<properties>
<revision>1.3.1<\/revision>
<changelist>-SNAPSHOT<\/changelist>
<sha1\/>
<\/properties>
<\/project>
Afgeleide
<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>
Als je versie 2.0.0-SNAPSHOT wilt bouwen, gebruik je gewoon
mvn -Drevision=2.0.0 clean package
Als je een release wilt maken, reset je gewoon de SNAPSHOT
mvn -Dchangelist= clean package
*De bovenstaande voorbeelden zijn genomen van de website van Maven Apache Project
De harde realiteit
Het is allemaal goed en wel, het is tijd om een gevoel van voldoening te ervaren, maar dat is niet het geval. Blijkbaar werkt deze methode niet voor install en deploy, omdat in de beschrijvingen van de artefacten die in de repository worden gepubliceerd, ${revision} niet zal worden vervangen door de waarde en Maven begrijpt dan helemaal niet waar het over gaat.
<parent>
<groupId>org.apache<\/groupId>
<artifactId>apache<\/artifactId>
<version>${revision}<\/version>
<\/parent>
Licht aan het einde van de tunnel
We moeten een oplossing voor het probleem zoeken. De situatie zou kunnen worden gered door Deze plugin staat alle variabelen in pom toe, maar snijdt ook een hoop andere informatie uit die alleen nodig is bij de build en niet bij het importeren van gepubliceerde artefacten in andere projecten. Daarnaast 'vereenvoudigt' de plugin alle parent-child afhankelijkheden, waardoor platte pom's ontstaan die alles bevatten wat nodig is. Het nadeel was dat hij te veel 'overbodige' informatie uitsnijdt, wat ons helemaal niet beviel. Na het bestuderen van informatie over de ontwikkeling van deze plugin, bleek dat we niet alleen in het universum waren; in augustus 2018 was er op GitHub in de repository van de plugin een pull-request aangemaakt met het verzoek om de mogelijkheid te creëren om zelf te bepalen hoe pom.xml 'veranderd' moet worden. De ontwikkelaars luisterden naar de stemmen van de behoeftigen, en in december, met de lancering van versie 1.1.0, werd de nieuwe modus resolveCiFriendliesOnly in de flatten-maven-plugin geïntroduceerd, die als nooit tevoren van pas kwam – het laat pom.xml intact behalve het element <version> en staat toe ${revision}, ${sha1} en ${changelist}.
We voegen de plugin aan het project toe
<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>
Klaar!
Happy end
Voortaan moeten we, om de versie van het hele project te wijzigen en dit aan alle afhankelijkheden te laten weten, slechts het element <revision> in slechts één enkele root pom.xml. Tijdens de review komen er niet honderden van deze bestanden met dezelfde wijziging binnen, maar één. En het is ook niet meer nodig om gebruik te maken van versions-maven-plugin.
Bron: habr.com
