Gebruik de nieuwste versie van een afhankelijkheid in Maven
1. Overzicht
Het handmatig upgraden van Maven-afhankelijkheden is altijd een vervelend werk geweest, vooral in projecten waarbij veel bibliotheken regelmatig worden vrijgegeven.
In deze tutorial leren we hoe de Versions Maven Plugin te gebruiken om onze afhankelijkheden up-to-date te houden.
Dit kan vooral erg handig zijn bij het implementeren van continue integratie-pijplijnen die automatisch de afhankelijkheden upgraden, testen of alles nog goed werkt, en het resultaat vastleggen of terugdraaien, afhankelijk van wat van toepassing is.
2. Syntaxis van het Maven-versiebereik
In de tijd van Maven2 konden ontwikkelaars versiebereiken specificeren waarbinnen de artefacten zouden zijn geüpgraded zonder de noodzaak van handmatige tussenkomst.
Deze syntaxis is nog steeds geldig, wordt in verschillende projecten gebruikt en is daarom de moeite waard om te weten:
Desalniettemin moeten we het indien mogelijk vermijden ten gunste van de Versions Maven-plug-in, omdat het naar voren brengen van concrete versies van buitenaf ons absoluut meer controle geeft dan Maven de hele operatie alleen te laten uitvoeren.
2.1. Verouderde syntaxis
Maven2 leverde ook twee speciale metaversiewaarden om het resultaat te bereiken: LAATSTE en VRIJLATING.
LAATSTE zoekt naar de nieuwste mogelijke versie, while VRIJLATING richt zich op de nieuwste niet-SNAPSHOT-versie.
Ze zijn inderdaad nog steeds absoluut geldig voor reguliere afhankelijkheden resolutie.
Deze oudere upgrademethode veroorzaakte echter onvoorspelbaarheid waar CI reproduceerbaarheid nodig had. Daarom zijn ze verouderd voor het oplossen van plug-in-afhankelijkheden.
3. Versies Maven Plugin
De Versions Maven-plug-in is de de facto standaardmanier om tegenwoordig met versiebeheer om te gaan.
Van vergelijkingen op hoog niveau tussen externe opslagplaatsen tot tijdstempels op laag niveau voor SNAPSHOT-versies, de enorme lijst met doelen stelt ons in staat om te zorgen voor elk aspect van onze projecten met afhankelijkheden.
Hoewel velen van hen buiten het bestek van deze tutorial vallen, laten we de tools die ons zullen helpen bij het upgradeproces eens nader bekijken.
3.1. De testcase
Laten we voordat we beginnen onze testcase definiëren:
- drie RELEASE's met een hardgecodeerde versie
- één RELEASE met een eigenschapsversie, en
- een SNAPSHOT
commons-io commons-io 2.3 org.apache.commons commons-collections4 4.0 org.apache.commons commons-lang3 3.0 org.apache.commons commons-comprimeer $ {commons-compress-versie} commons-beanutils commons-beanutils 1.9.1 -SNAPSHOT 1.15 Laten we tot slot ook een artefact uitsluiten van het proces bij het definiëren van de plug-in:
org.codehaus.mojo versies-maven-plugin 2.7 org.apache.commons: commons-collections4 4. Beschikbare updates weergeven
Allereerst, om gewoon te weten of en hoe we ons project kunnen updaten, de juiste tool voor de klus is versies: weergave-afhankelijkheid-updates:
mvn-versies: weergave-afhankelijkheid-updates
Zoals we kunnen zien, het proces omvatte elke RELEASE-versie. Het omvatte zelfs commons-collecties4 aangezien de uitsluiting in de configuratie verwijst naar het updateproces en niet naar het ontdekkingsproces.
Het negeerde daarentegen de SNAPSHOT, omdat het een ontwikkelingsversie is die vaak niet veilig kan worden bijgewerkt.
5. Bijwerken van de afhankelijkheden
Wanneer u voor het eerst een update uitvoert, maakt de plug-in een back-up van het pom.xml genaamd pom.xml.versions Back-up.
Hoewel elke iteratie het pom.xml, zal het back-upbestand de oorspronkelijke staat van het project behouden tot het moment dat de gebruiker zich vastlegt (via mvn-versies: commit) of terug te keren (door mvn-versies: revert) het hele proces.
5.1. SNAPSHOTs omzetten in RELEASEs
Het komt wel eens voor dat een project een SNAPSHOT bevat (een versie die nog volop in ontwikkeling is).
We kunnen gebruiken versies: use-releases om te controleren of de correspondent RELEASE is gepubliceerd, en nog meer om onze SNAPSHOT tegelijkertijd om te zetten in die RELEASE:
mvn-versies: use-releases 
5.2. Updaten naar de volgende RELEASE
We kunnen elke niet-SNAPSHOT-afhankelijkheid overzetten naar de dichtstbijzijnde versie met versies: use-next-releases:
mvn-versies: use-next-releases 
We kunnen duidelijk zien dat de plug-in is bijgewerkt commons-io, commons-lang3, en zelfs commons-beanutils, wat geen SNAPSHOT meer is, naar hun volgende versie.
Het belangrijkste was dat het genegeerd werd commons-collecties4, die is uitgesloten in de configuratie van de plug-in, en commons-comprimeren, dat een versienummer heeft dat dynamisch is opgegeven via een eigenschap.
5.3. Updaten naar de nieuwste RELEASE
Het bijwerken van elke niet-SNAPSHOT-afhankelijkheid naar de nieuwste release werkt op dezelfde manier, door simpelweg het doel te veranderen in versies: gebruik-laatste-releases:
mvn-versies: gebruik-laatste-releases 
6. Het filteren van ongewenste versies
Als we bepaalde versies willen negeren, kan de configuratie van de plug-in worden aangepast om regels dynamisch te laden vanuit een extern bestand:
org.codehaus.mojo versies-maven-plugin 2.7 //www.mijnbedrijf.com/maven-version-rules.xml Het meest opmerkelijk, kan ook verwijzen naar een lokaal bestand:
bestand: ///home/andrea/maven-version-rules.xml 6.1. Versies wereldwijd negeren
We kunnen ons regelsbestand zo configureren dat het negeert versies die overeenkomen met een specifieke reguliere expressie:
. * - bèta 6.2. Versies negeren per regel
Ten slotte, voor het geval onze behoeften specifieker zijn, kunnen we in plaats daarvan een reeks regels opstellen:
. * - RELEASE 2.1.0 7. Conclusie
We hebben gezien hoe we de afhankelijkheden van een project op een veilige, automatische en Maven3-compatibele manier kunnen controleren en bijwerken.
Zoals altijd is de broncode beschikbaar op GitHub, samen met een script om alles stap voor stap en zonder complexiteit te laten zien.
Om het in actie te zien, downloadt u eenvoudig het project en voert u het uit in een terminal (of in Git Bash als u Windows gebruikt):
./run-the-demo.sh
