Wie zijn wij?
Bij 1C ontwikkelen we niet alleen een platform op и , maar ook Java-applicaties - met name de nieuwe ontwikkelomgeving gebaseerd op Eclipse en een messenger-server die diep geïntegreerd is met het platform - .
Toegang
We gebruiken maven het vaakst als bouwsysteem voor Java-applicaties, en in dit korte artikel willen we het hebben over een van de problemen waarmee we te maken kregen bij het organiseren van ontwikkeling, en over de aanpak waarmee we dit konden overwinnen. probleem.
Vereisten en werkstroom
Vanwege de specifieke kenmerken van de ontwikkeling in onze maven-projecten, gebruiken we behoorlijk wat modules, afhankelijkheden en onderliggende projecten. Het aantal pom-bestanden in één boom kan tientallen of zelfs honderden bedragen.
Het lijkt erop: geen probleem, ze hebben het ooit gemaakt en zijn het vergeten. Als u in alle bestanden tegelijk iets wilt wijzigen of toevoegen, zijn er veel handige tools in editors en IDE's. Wat is de meest voorkomende reguliere wijziging in pom.xml? Wij zijn van mening dat er veranderingen optreden in projectversies en afhankelijkheden. Misschien wil iemand hier ruzie over maken, maar bij ons is dit precies de situatie. De reden ligt in het feit dat we, samen met de kernel, tegelijkertijd veel van onze eigen bibliotheken ontwikkelen, en vanwege de constante reproduceerbaarheid van bouw- en testresultaten lijkt het gebruik van snapshots ons geen handige aanpak. Om deze reden is het noodzakelijk om bij elke build het versienummer in projecten te verhogen.
Ook moet een ontwikkelaar van tijd tot tijd zijn eigen tak van een bibliotheek bouwen en de functionaliteit ervan controleren op basis van alle afhankelijkheden, waarvoor hij de versie van alle afhankelijkheden handmatig moet wijzigen.
Eerste oplossing
Met zulke frequente en meerdere versiewijzigingen wil ik het proces binnen CI vereenvoudigen en automatiseren. Dit is waar een handige, bekende plug-in te hulp komt. versies-maven-plugin - sluit het aan en start het
mvn -N versies:set -DnewVersion=2.0.1
en Maven zal alles doen zoals het hoort: het zal de hiërarchie van boven naar beneden doorlopen en alle versies vervangen - schoonheid! Nu hoeft u alleen nog maar een pull-verzoek in te dienen, collega's zullen de wijzigingen bekijken en u kunt snel lid worden van de trunk. Snel? Hoe het ook is. Een paar honderd pom.xml ter beoordeling, en hierbij wordt de code niet meegeteld. Bovendien is niemand veilig voor samenvoegconflicten met zo'n groot aantal gewijzigde bestanden. Hierbij moet worden opgemerkt dat versiewijzigingen in het CI-proces automatisch plaatsvinden samen met wijzigingen in de functionaliteit, en niet op de een of andere manier afzonderlijk.
Nieuwe functies
Een tijdje werden we gekalmeerd en berustend leefden we zo totdat de jongens wegkwamen Vanaf versie 3.5.0-beta-1 bood Maven geen ondersteuning voor zogenaamde “placeholders”. De essentie van deze vervangers is dat pom.xml in plaats van een specifieke aanduiding van de projectversie worden variabelen gebruikt ${revisie}, ${sha1} и ${wijzigingslijst}. De waarden van deze eigenschappen zelf worden in het element ingesteldvastgoed>, of ze kunnen worden gedefinieerd via een systeemeigenschap
mvn -Drevision=2.0.0 schoon pakket
Systeemeigenschapswaarden hebben voorrang op de waarden die zijn gedefinieerd invastgoed>.
De ouder
4.0.0
org.apache
apache
18
org.apache.maven.ci
ci-ouder
Eerste CI-vriendelijk
${revisie}${sha1}${changelist}
...
1.3.1
-MOMENTOPNAME
Afstammeling
4.0.0
org.apache.maven.ci
ci-ouder
${revisie}${sha1}${changelist}
org.apache.maven.ci
ci-kind
...
Als je versie 2.0.0-SNAPSHOT wilt bouwen, gebruik dan gewoon
mvn -Drevision=2.0.0 schoon pakket
Als je een release wilt maken, reset dan gewoon SNAPSHOT
mvn -Dchangelist= schoon pakket
*De bovenstaande voorbeelden zijn afkomstig uit op de Maven Apache Project-website
harde realiteit
Alles is goed en gezond, het is tijd om een gevoel van voldoening te voelen, maar nee. Het blijkt dat deze methode niet zal werken voor installatie en implementatie, omdat deze niet zal worden vervangen in de beschrijvingen van artefacten die in de repository worden gepubliceerd ${revisie} over de betekenis ervan en maven zal niet langer begrijpen waar het allemaal om draait.
org.apache
apache
${revisie}
Een licht in het einde van een tunnel
We moeten op zoek gaan naar een oplossing voor het probleem. Had de situatie kunnen redden . Deze plug-in lost alle variabelen in de pom op, maar verwijdert tegelijkertijd een heleboel andere informatie die alleen nodig is tijdens de montage en niet nodig is bij het importeren van gepubliceerde artefacten in andere projecten. De plug-in maakt ook alle afhankelijkheden tussen ouders en kinderen recht, en als resultaat krijg je een platte pom die alles bevat wat je nodig hebt. Het ongemak was dat er te veel “extra” werd weggelaten, wat helemaal niet bij ons paste. Na het bestuderen van de informatie over de ontwikkeling van deze plug-in, bleek dat we niet de enigen in het universum zijn, en in augustus 2018 werd een pull-request gemaakt op Github in de plug-in-repository met de wens om dit mogelijk te maken om zelf te bepalen hoe we pom.xml kunnen “verpesten”. De ontwikkelaars luisterden naar de stemmen van degenen die lijden, en al in december, met de release van de nieuwe versie 1.1.0, verscheen een nieuwe modus, solveCiFriendliesOnly, in de flatten-maven-plug-in, die geschikter was dan ooit - het laat pom.xml zoals het is, behalve het element en staat toe ${revisie}, ${sha1} и ${wijzigingslijst}.
Een plug-in aan het project toevoegen
org.codehaus.mojo
flatten-maven-plug-in
1.1.0
WAAR
oplossingCiFriendliesOnly
afvlakken
proces-middelen
afvlakken
plat.schoon
schoon
schoon
Klaar!
Gelukkig einde
Om de versie van het hele project te wijzigen en alle afhankelijkheden hiervan op de hoogte te stellen, hoeven we vanaf nu alleen maar het element te bewerkenherziening> alleen in de root pom.xml. Er komen niet honderd of twee van deze bestanden met dezelfde wijziging bij de beoordeling, maar één. Nou, het is niet nodig om te gebruiken versies-maven-plugin.
Bron: www.habr.com