streamalism.org

1. Oversigt

Opgradering af Maven-afhængigheder manuelt har altid været et kedeligt arbejde, især i projekter med mange biblioteker, der ofte frigives.

I denne vejledning lærer vi hvordan man udnytter Versions Maven Plugin for at holde vores afhængigheder opdaterede.

Frem for alt kan dette være yderst nyttigt ved implementering af kontinuerlige integrationsrørledninger, der automatisk opgraderer afhængighederne, tester, at alt stadig fungerer korrekt, og begår eller tilbagefører resultatet, alt efter hvad der er passende.

2. Syntaks for Maven Version Range

Tilbage i Maven2-dage kunne udviklere specificere versioner, inden for hvilke artefakterne ville være blevet opgraderet uden behov for en manuel indgriben.

Denne syntaks er stadig gyldig, bruges i flere projekter derude og er derfor værd at vide:

Ikke desto mindre bør vi undgå det til fordel for Versions Maven Plugin, når det er muligt, fordi avancerede konkrete versioner udefra giver os bestemt mere kontrol end at lade Maven håndtere hele operationen alene.

2.1. Forældet syntaks

Maven2 leverede også to specielle metaversionsværdier for at opnå resultatet: SENESTE og FRIGØRE.

SENESTE ser efter den nyeste mulige version, mens FRIGØRE sigter mod den seneste version, der ikke er SNAPSHOT.

De er faktisk stadig absolut gyldig for regelmæssige afhængigheder løsning.

Denne ældre opgraderingsmetode forårsagede imidlertid uforudsigelighed, hvor CI havde brug for reproducerbarhed. Derfor er de blevet udfaset for løsning af afhængighed af plugin.

3. Versioner Maven Plugin

Versions Maven Plugin er den de facto standard måde at håndtere version management på i dag.

Fra sammenligninger på højt niveau mellem fjernopbevaringssteder til lavt niveau tidsstemplingslåsning for SNAPSHOT-versioner giver dens massive liste over mål os mulighed for at tage sig af alle aspekter af vores projekter, der involverer afhængigheder.

Mens mange af dem er uden for omfanget af denne vejledning, lad os se nærmere på dem, der vil hjælpe os i opgraderingsprocessen.

3.1. Testsagen

Lad os definere vores testsag inden start:

• tre RELEASE'er med en hårdkodet version
• en RELEASE med en ejendomsversion, og
• et SNAPSHOT

  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 

Endelig lad os også udelukke en artefakt fra processen, når vi definerer pluginet:

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

4. Visning af tilgængelige opdateringer

Først og fremmest, for blot at vide, om og hvordan vi kan opdatere vores projekt, det rigtige værktøj til jobbet er versioner: opdateringer til skærmafhængighed:

mvn-versioner: skærmafhængighedsopdateringer

Som vi kan se, processen omfattede hver RELEASE-version. Det inkluderede endda fælles-samlinger4 da udelukkelsen i konfigurationen refererer til opdateringsprocessen og ikke til opdagelsesprocessen.

I modsætning hertil ignorerede det SNAPSHOT af grunden til, at det er en udviklingsversion, der ofte ikke er sikkert at opdatere automatisk.

5. Opdatering af afhængigheder

Når du kører en opdatering for første gang, opretter pluginet en sikkerhedskopi af pom.xml som hedder pom.xml.versionsBackup.

Mens hver iteration vil ændre pom.xml, vil backupfilen bevare projektets oprindelige tilstand indtil det øjeblik brugeren vil begå (igennem mvn versioner: commit) eller vende tilbage (gennem mvn versioner: vende tilbage) hele processen.

5.1. Konvertering af SNAPSHOTs til RELEASEs

Det sker nogle gange, at et projekt inkluderer et SNAPSHOT (en version, der stadig er under kraftig udvikling).

Vi kan bruge versioner: brugsudgivelser for at kontrollere, om korrespondenten RELEASE er blevet offentliggjort, og endnu mere for at konvertere vores SNAPSHOT til den RELEASE på samme tid:

mvn versioner: brugsudgivelser 

5.2. Opdatering til den næste RELEASE

Vi kan porte enhver ikke-SNAPSHOT-afhængighed til den nærmeste version med versioner: brug-næste udgivelser:

mvn versioner: use-next-releases 

Vi kan tydeligt se, at pluginet er opdateret commons-io, commons-lang3, og endda commons-beanutils, som ikke længere er et SNAPSHOT til deres næste version.

Vigtigst er det, det ignoreres commons-samlinger4, som er udelukket i plugin-konfigurationen, og commons-compress, som har et versionsnummer, der er angivet dynamisk gennem en ejendom.

5.3. Opdatering til den seneste RELEASE

Opdatering af enhver ikke-SNAPSHOT-afhængighed til den seneste udgivelse fungerer på samme måde og ændrer blot målet til versioner: brug-nyeste udgivelser:

mvn-versioner: brug-nyeste udgivelser 

6. Filtrering af uønskede versioner

Hvis vi vil ignorere visse versioner, kan plugin-konfigurationen indstilles for at indlæse regler dynamisk fra en ekstern fil:

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

Mest bemærkelsesværdige, kan også henvise til en lokal fil:

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

6.1. Ignorer versioner globalt

Vi kan konfigurere vores regelsæt, så det det ignorerer versioner, der matcher et specifikt regulært udtryk:

  . * - beta 

6.2. Ignorer versioner pr. Regel

Endelig, hvis vores behov er mere specifikke, kan vi i stedet bygge et sæt regler:

    . * - UDGIVELSE 2.1.0 

7. Konklusion

Vi har set, hvordan vi kontrollerer og opdaterer afhængighederne i et projekt på en sikker, automatisk og Maven3-kompatibel måde.

Som altid er kildekoden tilgængelig på GitHub sammen med et script, der hjælper med at fremvise alt trin for trin og uden kompleksitet.

For at se det i aktion skal du blot downloade projektet og køre i en terminal (eller i Git Bash, hvis du bruger Windows):

./kør-demo.sh