Bruk den siste versjonen av en avhengighet i Maven

1. Oversikt

Å oppgradere Maven-avhengigheter manuelt har alltid vært et kjedelig arbeid, spesielt i prosjekter med mange biblioteker som slippes ofte.

I denne opplæringen lærer vi hvordan du utnytter Versions Maven Plugin for å holde avhengighetene våre oppdaterte.

Fremfor alt kan dette være ekstremt nyttig når du implementerer kontinuerlige integrasjonsrørledninger som automatisk oppgraderer avhengighetene, tester at alt fortsatt fungerer som det skal, og forplikter eller tilbakestiller resultatet, avhengig av hva som er passende.

2. Syntaks for Maven versjonsområde

Tilbake i Maven2-dagene kunne utviklere spesifisere versjonsområder der gjenstandene ville blitt oppgradert uten behov for manuell inngrep.

Denne syntaksen er fortsatt gyldig, brukt i flere prosjekter der ute og er derfor verdt å vite:

Ikke desto mindre bør vi unngå det til fordel for Versions Maven Plugin når det er mulig, fordi fremrykkende konkrete versjoner fra utsiden gir oss definitivt mer kontroll enn å la Maven håndtere hele operasjonen alene.

2.1. Utfaset syntaks

Maven2 ga også to spesielle metaversjonsverdier for å oppnå resultatet: SISTE og UTGIVELSE.

SISTE ser etter den nyeste mulige versjonen, mens UTGIVELSE sikter mot den siste ikke-SNAPSHOT-versjonen.

De er faktisk fortsatt absolutt gyldig for vanlige avhengigheter Vedtak.

Imidlertid forårsaket denne eldre oppgraderingsmetoden uforutsigbarhet der CI trengte reproduserbarhet. Derfor har de blitt utfaset for løsning av plugin-avhengighet.

3. Versjoner Maven Plugin

Versions Maven Plugin er de facto standard måten å håndtere versjonsadministrasjon i dag.

Fra sammenligninger på høyt nivå mellom eksterne lagringssteder og til tidsnivåsperring på lavt nivå for SNAPSHOT-versjoner, gir den enorme listen over mål oss mulighet til å ta vare på alle aspekter av våre prosjekter som involverer avhengigheter.

Mens mange av dem er utenfor omfanget av denne opplæringen, la oss se nærmere på de som vil hjelpe oss i oppgraderingsprosessen.

3.1. Test saken

Før vi begynner, la oss definere testsaken vår:

  • tre RELEASEs med en hardkodet versjon
  • en RELEASE med en eiendomsversjon, og
  • ett STILLBILDE
  commons-io commons-io 2.3 org.apache.commons commons-collection4 4.0 org.apache.commons commons-lang3 3.0 org.apache.commons commons-compress $ {commons-compress-version} commons-beanutils commons-beanutils 1.9.1 -SNAPSHOT 1.15 

Til slutt, la oss også ekskludere en gjenstand fra prosessen når vi definerer plugin:

   org.codehaus.mojo versjoner-maven-plugin 2.7 org.apache.commons: commons-collection4 

4. Viser tilgjengelige oppdateringer

Først av alt, å bare vite om og hvordan vi kan oppdatere prosjektet vårt, det rette verktøyet for jobben er versjoner: skjermavhengighetsoppdateringer:

mvn versjoner: skjermavhengighetsoppdateringer

Som vi kan se, prosessen inkluderte hver RELEASE-versjon. Det inkluderte til og med felles-samlinger4 siden ekskluderingen i konfigurasjonen refererer til oppdateringsprosessen, og ikke til oppdagelsen.

Derimot ignorerte den SNAPSHOT, av den grunn at det er en utviklingsversjon som ofte ikke er trygt å oppdatere automatisk.

5. Oppdatere avhengighetene

Når du kjører en oppdatering for første gang, oppretter programtillegget en sikkerhetskopi av pom.xml heter pom.xml.versionsBackup.

Mens hver iterasjon vil endre pom.xml, vil sikkerhetskopifilen bevare den opprinnelige tilstanden til prosjektet frem til det øyeblikket brukeren vil forplikte seg (gjennom mvn versjoner: commit) eller gå tilbake (gjennom mvn versjoner: tilbakestill) hele prosessen.

5.1. Konvertering av SNAPSHOTs til RELEASEs

Noen ganger hender det at et prosjekt inkluderer et SNAPSHOT (en versjon som fremdeles er under tung utvikling).

Vi kan bruke versjoner: bruk-utgivelser for å sjekke om korrespondenten RELEASE er publisert, og enda mer for å konvertere vår SNAPSHOT til den RELEASE samtidig:

mvn versjoner: bruk-utgivelser 

5.2. Oppdaterer til Neste RELEASE

Vi kan portere hver ikke-SNAPSHOT-avhengighet til nærmeste versjon med versjoner: bruk neste utgivelser:

mvn-versjoner: bruk neste utgivelser 

Vi kan tydelig se at programtillegget ble oppdatert commons-io, commons-lang3, Til og med commons-beanutils, som ikke er et SNAPSHOT lenger, til neste versjon.

Viktigst, det ignoreres commons-samlinger4, som er ekskludert i plugin-konfigurasjonen, og commons-compress, som har et versjonsnummer spesifisert dynamisk gjennom en eiendom.

5.3. Oppdaterer til den siste RELEASE

Oppdatering av hver avhengighet som ikke er SNAPSHOT til den siste utgivelsen, fungerer på samme måte, bare ved å endre målet til versjoner: bruk-nyeste utgivelser:

mvn-versjoner: bruk-nyeste utgivelser 

6. Filtrering av uønskede versjoner

I tilfelle vi vil ignorere visse versjoner, kan plugin-konfigurasjonen stilles inn for å laste inn regler dynamisk fra en ekstern fil:

 org.codehaus.mojo versjoner-maven-plugin 2.7 //www.mycompany.com/maven-version-rules.xml 

Mest bemerkelsesverdig, kan også referere til en lokal fil:

fil: ///home/andrea/maven-version-rules.xml 

6.1. Ignorer versjoner globalt

Vi kan konfigurere reglefilen vår slik at det ignorerer versjoner som samsvarer med et bestemt regulært uttrykk:

  . * - beta 

6.2. Ignorer versjoner etter regel

Til slutt, hvis våre behov er mer spesifikke, kan vi i stedet bygge et sett med regler:

    . * - RELEASE 2.1.0 

7. Konklusjon

Vi har sett hvordan vi kan sjekke og oppdatere avhengighetene til et prosjekt på en sikker, automatisk og Maven3-kompatibel måte.

Som alltid er kildekoden tilgjengelig på GitHub, sammen med et skript som hjelper deg med å presentere alt trinn for trinn og uten kompleksitet.

For å se det i aksjon, laster du bare ned prosjektet og kjører i en terminal (eller i Git Bash hvis du bruker Windows):

./kjør-demo.sh

$config[zx-auto] not found$config[zx-overlay] not found