Hoe vertel ik Maven om de laatste versie van een afhankelijkheid gebruiken?

stemmen
644

In Maven, zijn afhankelijkheden meestal opgezet als volgt uit:

<dependency>
  <groupId>wonderful-inc</groupId>
  <artifactId>dream-library</artifactId>
  <version>1.2.3</version>
</dependency>

Nu, als u werkt met bibliotheken die frequente releases hebben, voortdurend bezig de <version> tag kan een beetje vervelend. Is er een manier om Maven vertellen om altijd gebruik maken van de meest recente versie (van de repository)?

De vraag is gesteld op 27/08/2008 om 17:17
bron van user
In andere talen...                            


12 antwoorden

stemmen
633

NOTITIE:

Dit antwoord is van toepassing op 2 alleen Maven! De genoemde LATESTen RELEASEmetaversions zijn in Maven 3 laten vallen "in het belang van reproduceerbare bouwt" , meer dan 6 jaar geleden. Raadpleeg deze Maven 3 compliant oplossing .


Als u wilt altijd de nieuwste versie te gebruiken, Maven heeft twee zoekwoorden die u kunt gebruiken als een alternatief voor de versie bereiken. U dient deze opties te gebruiken met zorg als je niet langer de controle over de plugins / afhankelijkheden die u gebruikt.

Als je afhankelijk van een plugin of een afhankelijkheid, kunt u het een versie waarde van de meest recente of RELEASE gebruiken. LAATSTE verwijst naar de laatste vrijgegeven of snapshot versie van een bepaald artefact, de meest recent ingezet artefact in een bepaalde repository. RELEASE verwijst naar de laatste niet-snapshot release in de repository. In het algemeen is het niet een best practice om software die afhankelijk is van een niet-specifieke versie van een artefact te ontwerpen. Als je de ontwikkeling van software, wilt u misschien RELEASE of LAATSTE gebruiken voor uw gemak, zodat u niet hoeft te versienummers bijgewerkt wanneer een nieuwe versie van een derde partij bibliotheek wordt losgelaten. Wanneer u software vrij te geven, moet je altijd zorgen dat uw project hangt af van de specifieke versies om de kansen van uw bouwen of uw project wordt beïnvloed door een software release niet onder uw controle te verminderen. Gebruiken de nieuwste en RELEASE met de nodige voorzichtigheid, of helemaal niet.

Zie de POM Syntax sectie van het Maven boek voor meer informatie. Of zie deze doc op Dependency Version Ranges , waarbij:

  • Een vierkante haak ( [en ]) betekent "gesloten" (inclusief).
  • A haakjes ( (en )) betekent "open" (exclusief).

Hier is een voorbeeld ter illustratie van de verschillende opties. In de Maven repository, com.foo:my-foo heeft de volgende metadata:

<?xml version="1.0" encoding="UTF-8"?><metadata>
  <groupId>com.foo</groupId>
  <artifactId>my-foo</artifactId>
  <version>2.0.0</version>
  <versioning>
    <release>1.1.1</release>
    <versions>
      <version>1.0</version>
      <version>1.0.1</version>
      <version>1.1</version>
      <version>1.1.1</version>
      <version>2.0.0</version>
    </versions>
    <lastUpdated>20090722140000</lastUpdated>
  </versioning>
</metadata>

Als een afhankelijkheid die artefact nodig is, hebt u de volgende opties (andere versie bereiken kan worden gespecificeerd uiteraard enkel het tonen van de relevante degenen hier):

Verklaar een exacte versie (altijd besluiten tot 1.0.1):

<version>[1.0.1]</version>

Verklaar een expliciete versie (altijd besluiten tot 1.0.1, tenzij er een botsing optreedt, wanneer Maven een bijpassende versie te selecteren):

<version>1.0.1</version>

Verklaar een versie bereik voor alle 1.x (wordt momenteel besluiten tot 1.1.1):

<version>[1.0.0,2.0.0)</version>

Verklaar een open-ended versie bereik (zal besluiten tot 2.0.0):

<version>[1.0.0,)</version>

Verklaar de versie zoals LAATSTE (zal besluiten tot 2.0.0) (verwijderd uit maven 3.x)

<version>LATEST</version>

Verklaar de versie zoals RELEASE (zal besluiten tot 1.1.1) (verwijderd uit maven 3.x):

<version>RELEASE</version>

Merk op dat standaard uw eigen implementaties zal de "laatste" binnenkomst in de Maven metadata bij te werken, maar om de "release" entry bijwerken, moet u de "release-profile" uit het activeren Maven super POM . U kunt dit doen met ofwel "-Prelease-profile" of "-DperformRelease = true"


Het is de moeite waard te benadrukken dat elke benadering die het mogelijk maakt Maven om de afhankelijkheid versies (UITERLIJK RELEASE, en versie bereiken) halen kunnen achterlaten als u open te stellen voor kwesties in verband op te bouwen, zoals later versies verschillend gedrag kunnen hebben (bijvoorbeeld de afhankelijkheid plugin eerder overgestapt van een standaard waarde van true in false, met verwarrende resultaten).

Het is daarom in het algemeen een goed idee om de exacte versies in releases definiëren. Zoals Tim's antwoord opmerkt, de expert-versies-plugin is een handig hulpmiddel voor het bijwerken van de afhankelijkheid versies, met name de versies: gebruik-latest-versies en versies: gebruik-latest-releases doelen.

antwoordde op 23/07/2009 om 15:58
bron van user

stemmen
307

Nu weet ik dat dit onderwerp is oud, maar het lezen van de vraag en het OP meegeleverde antwoord lijkt de Maven Versies Plugin misschien eigenlijk een beter antwoord op zijn vraag geweest:

In het bijzonder zou de volgende doelstellingen van nut zijn:

  • uitvoeringen: use-nieuwste versies zoekt de pom voor alle versies waarvoor een nieuwe versie zijn geweest en vervangt ze door de meest recente versie.
  • uitvoeringen: use-nieuwste releases doorzoekt de pom voor alle niet-SNAPSHOT versies waarvoor een nieuwe versie zijn geweest en vervangt ze door de meest recente versie release.
  • uitvoeringen:-update-eigenschappen werkt eigenschappen die zijn gedefinieerd in een project, zodat ze overeenkomen met de meest recente versie van de specifieke afhankelijkheden. Dit kan handig zijn als een suite van afhankelijkheden moeten allemaal worden vergrendeld om één versie.

De volgende andere doelen zijn ook aanwezig:

  • versies: weergave-dependency-updates scant afhankelijkheden van een project en maakt een rapport van de afhankelijkheden die nieuwere versies beschikbaar zijn.
  • versies: weergave-plugin-updates scant plugins van een project en maakt een rapport van de plugins die nieuwere versies beschikbaar zijn.
  • uitvoeringen:-update-ouder werkt de ouder gedeelte van een project, zodat het de nieuwste beschikbare versie gevonden. Bijvoorbeeld, als u een corporate wortel POM gebruiken, dit doel kan handig zijn als je nodig hebt om ervoor te zorgen dat u de nieuwste versie van de corporate wortel POM.
  • uitvoeringen:-update-kind-modules werkt de ouder gedeelte van het kind modules van een project, zodat de versie die overeenkomt met de versie van het huidige project. Bijvoorbeeld, als u een aggregator pom dat is ook de ouder voor de projecten die zij verzamelt en de kinderen en de ouder-versies niet meer synchroon, kan deze mojo helpen vast te stellen de versies van het kind modules. (Let op je kan nodig zijn om Maven te roepen met de -N optie om dit doel te lopen als je project zo slecht dat het niet kan bouwen, omdat de versie mis-match is gebroken).
  • uitvoeringen: lock-snapshots doorzoekt de pom voor alle -SNAPSHOT versies en vervangt ze door de huidige timestamp versie van die -SNAPSHOT, bijvoorbeeld -20090327.172306-4
  • uitvoeringen: unlock-snapshots doorzoekt de pom voor alle timestamp vergrendelde snapshot versies en vervangt ze door -SNAPSHOT.
  • uitvoeringen: resolve-ranges vindt dependencies met behulp van versie ranges en lost het bereik van de specifieke versie die wordt gebruikt.
  • uitvoeringen: use-releases doorzoekt de pom voor alle -SNAPSHOT versies die zijn vrijgelaten en vervangt ze door de bijbehorende release versie.
  • uitvoeringen: use-next-releases doorzoekt de pom voor alle niet-SNAPSHOT versies waarvoor een nieuwe versie zijn geweest en vervangt ze door de volgende release versie.
  • uitvoeringen: use-next-versies zoekt de pom voor alle versies waarvoor een nieuwe versie zijn geweest en vervangt ze door de volgende versie.
  • versies: plegen verwijdert de pom.xml.versionsBackup bestanden. Vormt de ene helft van de ingebouwde "Poor Man's SCM".
  • versies: revert herstelt de pom.xml bestanden van de pom.xml.versionsBackup bestanden. Vormt de ene helft van de ingebouwde "Poor Man's SCM".

Net dacht dat ik het onder andere voor eventuele toekomstige referentie.

antwoordde op 23/07/2009 om 17:03
bron van user

stemmen
162

Neem een kijkje op deze pagina (hoofdstuk "Afhankelijkheid Version Ranges"). Wat je zou willen doen is iets als

<version>[1.2.3,)</version>

Deze versie bereiken worden geïmplementeerd in Maven2.

antwoordde op 27/08/2008 om 17:56
bron van user

stemmen
72

In tegenstelling tot anderen Ik denk dat er zijn vele redenen waarom je zou altijd de nieuwste willen versie. Vooral als je aan het doen zijn continue inzet (we hebben soms als 5 releases in een dag) en willen niet om een multi-module project te doen.

Wat ik doe is het maken van Hudson / Jenkins doe het volgende voor elke build:

mvn clean versions:use-latest-versions scm:checkin deploy -Dmessage="update versions" -DperformRelease=true

Dat wil zeggen dat ik de versies plugin en scm plugin om de afhankelijkheden te werken en vervolgens te controleren in om de bron te controleren. Ja, ik laat mijn CI doen SCM checkins (die je moet toch te doen voor de Maven vrijlating plugin).

U wilt instellen van de versies plugin om alleen te werken wat je wilt:

        <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>versions-maven-plugin</artifactId>
            <version>1.2</version>
            <configuration>
                <includesList>com.snaphop</includesList>
                <generateBackupPoms>false</generateBackupPoms>
                <allowSnapshots>true</allowSnapshots>
            </configuration>
        </plugin>

Ik gebruik de release plugin om de release die zorgt voor -SNAPSHOT en valideert dat er een versie van -SNAPSHOT (wat belangrijk is) te doen.

Als je doet wat ik doen moet je de laatste versie te krijgen voor alle momentopname bouwt en de meest recente versie voor een release builds. Je bouwt zal ook reproduceerbaar zijn.

Bijwerken

Ik merkte een aantal opmerkingen te vragen een aantal specifieke kenmerken van deze workflow. Ik zal zeggen dat we deze methode niet meer te gebruiken en de grote reden waarom is de Maven versies plugin is buggy en in het algemeen is inherent gebrekkig.

Het is onjuist, omdat de versies plugin versies alle bestaande versies moeten bestaan ​​voor de pom om goed te werken aan te passen lopen. Dat is de versies plugin kan niet updaten naar de nieuwste versie van om het even wat als het de versie waarnaar in de pom niet kan vinden. Dit is eigenlijk een beetje vervelend omdat we vaak cleanup oude versies voor schijfruimte redenen.

Echt heb je een aparte tool van expert naar de versies aan te passen (zodat je niet afhankelijk zijn van de pom-bestand om correct te kunnen werken). Ik heb een dergelijk instrument geschreven in de de nederige taal die Bash. Het script zal de versies zoals de versie plugin bij te werken en controleer de pom terug in de bron te controleren. Het loopt ook graag 100x sneller dan de MVN versies plugin. Helaas is het niet op een manier geschreven voor publiek gebruik, maar als mensen die geïnteresseerd zijn kon ik het zo te maken en zet het in een kern of GitHub.

Teruggaan naar workflow als enkele opmerkingen gevraagd over dat dit is wat we doen:

  1. We hebben een 20-tal projecten in hun eigen repositories met hun eigen jenkins banen
  2. Toen we laat de Maven vrijlating plugin wordt gebruikt. De workflow van die wordt behandeld in de documentatie van de plugin's. De Maven vrijlating plugin soort zuigt (en ik ben vriendelijk zijn), maar het werkt wel. Op een dag zijn we van plan over deze methode te vervangen door iets meer optimaal.
  3. Wanneer één van de projecten wordt vrijgegeven Jenkins loopt dan een speciale baan zullen we de update roepen alle versies baan (hoe Jenkins kent zijn een release is een ingewikkelde manier voor een deel omdat de Maven Jenkins vrijkomen plugin is redelijk waardeloze ook).
  4. De update alle versies job hoogte is van alle 20 projecten. Het is eigenlijk een aggregator pom specifiek alle projecten in de sectie modules afhankelijk om te. Jenkins loopt onze magic groovy / bash foo dat zal trekken alle projecten het actualiseren van de versies van de nieuwste en vervolgens checkin de poms (weer gedaan in afhankelijkheid volgorde op basis van de sectie modules).
  5. Voor elk project als de pom is veranderd (als gevolg van een versie verandering in sommige afhankelijkheid) wordt nagegaan in en dan gaan we meteen pingen Jenkins naar de corresponderende job te laten lopen voor dat project (dit is om te bouwen afhankelijkheid orde te handhaven anders je bent overgeleverd aan de genade van de SCM Poll scheduler).

Op dit punt ben ik van mening dat het een goede zaak om de introductie en auto-versie toch hebben een aparte tool van uw algemene build.

Nu zou je denken Maven soort zuigt als gevolg van de hierboven genoemde problemen, maar dit zou eigenlijk vrij moeilijk met een ingebouwde tool die geen declaratieve gemakkelijk te ontleden heeft zijn uitschuifbare syntax (aka XML).

In feite voegen we aangepaste XML-attributen door middel van namespaces om hint bash helpen / groovy scripts (bijv doen deze versie niet updaten).

antwoordde op 09/01/2012 om 22:21
bron van user

stemmen
26

De afhankelijkheden syntax is gelegen aan de Dependency Version Requirement Specification documentatie. Hier wordt voor de volledigheid:

Afhankelijkheden versionelement definiëren versie vereisten, gebruikt om de effectieve afhankelijkheid versie te berekenen. Versie eisen hebben de volgende syntaxis:

  • 1.0: "Soft" eis op 1,0 (op slechts een aanbeveling, als het komt overeen met alle andere bereiken voor de afhankelijkheid)
  • [1.0]: "Hard" eis op 1,0
  • (,1.0]: X <= 1,0
  • [1.2,1.3]1.2 <= x <= 1,3
  • [1.0,2.0)1,0 <x <2,0
  • [1.5,): X> = 1,5
  • (,1.0],[1.2,): X <= 1,0 en x> = 1,2; complete sets Kommagescheiden
  • (,1.1),(1.1,): Dit is exclusief 1,1 (bijvoorbeeld wanneer bekend staan ​​voor gebruik in combinatie met deze bibliotheek)

In uw geval, zou je zoiets doen <version>[1.2.3,)</version>

antwoordde op 22/07/2015 om 16:21
bron van user

stemmen
14

Bent u eventueel afhankelijk van de ontwikkeling van versies die duidelijk tijdens de ontwikkeling veel veranderen?

In plaats van het verhogen van de versie van de ontwikkeling releases, kun je gewoon gebruik maken van een snapshot versie die u overschrijven wanneer dat nodig is, wat betekent dat je zou niet de versie tag te veranderen op elke kleine verandering. Iets als 1.0-SNAPSHOT ...

Maar misschien je probeert om iets anders te bereiken;)

antwoordde op 27/08/2008 om 17:30
bron van user

stemmen
6

Wie ooit met de nieuwste, zorg ervoor dat je -U anders de laatste snapshot zal niet worden getrokken.

mvn -U dependency:copy -Dartifact=com.foo:my-foo:LATEST
// pull the latest snapshot for my-foo from all repositories
antwoordde op 03/08/2015 om 08:38
bron van user

stemmen
5

Tegen de tijd dat deze vraag werd gesteld waren er enkele knikken met versie bereiken in Maven, maar deze zijn opgelost in nieuwere versies van Maven. Dit artikel legt heel goed hoe versie varieert werk en best practices om beter te begrijpen hoe Maven begrijpt versies: https://docs.oracle.com/middleware/1212/core/MAVEN/maven_version.htm#MAVEN8855

antwoordde op 03/04/2015 om 16:00
bron van user

stemmen
3

De waarheid is, zelfs in 3.x het nog werkt, verrassend de projecten bouwt en implementeert. Maar de nieuwste / RELEASE trefwoord problemen veroorzaakt in M2e en verduistering all over the place, OOK projecten hangt af van de afhankelijkheid die ingezet via de nieuwste / RELEASE falen om de versie te herkennen.

Het zal ook het veroorzaken van problemen als je probeert om de versie als eigendom te definiëren, en anders waar verwijzen naar het.

Dus de conclusie is gebruik maken van de versies-maven-plugin als je kunt.

antwoordde op 26/06/2015 om 15:53
bron van user

stemmen
2

Soms heb je niet wilt versie ranges te gebruiken, omdat het lijkt erop dat ze "langzaam" om uw afhankelijkheden op te lossen, vooral wanneer er continue afgifte op zijn plaats en er zijn vele versies - vooral tijdens zware ontwikkeling.

Een mogelijke oplossing zou zijn om de te gebruiken versies-maven-plugin . Bijvoorbeeld, kunt u een vermogen op te geven:

<properties>
    <myname.version>1.1.1</myname.version>
</properties>

en voeg de versies-maven-plugin om uw pom-bestand:

<build>
    <plugins>
        <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>versions-maven-plugin</artifactId>
            <version>2.3</version>
            <configuration>
                <properties>
                    <property>
                        <name>myname.version</name>
                        <dependencies>
                            <dependency>
                                <groupId>group-id</groupId>
                                <artifactId>artifact-id</artifactId>
                                <version>latest</version>
                            </dependency>
                        </dependencies>
                    </property>
                </properties>
            </configuration>
        </plugin>
    </plugins>
</build>

Dan, om de afhankelijkheid te werken, moet je de doelen uit te voeren:

mvn versions:update-properties validate

Als er een versie hoger dan 1.1.1, zal het u vertellen:

[INFO] Updated ${myname.version} from 1.1.1 to 1.3.2
antwoordde op 08/05/2017 om 15:59
bron van user

stemmen
1

MY oplossing in Maven 3.5.4, gebruik nexus, in eclipse:

<dependency>
    <groupId>yilin.sheng</groupId>
    <artifactId>webspherecore</artifactId>
    <version>LATEST</version> 
</dependency>

dan in eclipse: atl + F5en kies deforce update of snapshots/release

het werkt voor mij.

antwoordde op 07/10/2018 om 03:52
bron van user

stemmen
0

Als u wilt dat Maven moet de laatste versie te gebruiken van een afhankelijkheid, dan kunt u gebruik maken van versies Maven Plugin en hoe deze plugin te gebruiken, heeft Tim al een goed antwoord gegeven, volg zijn antwoord .

Maar als ontwikkelaar, zal ik niet dit soort praktijken te bevelen. WAAROM?

antwoord op waarom is reeds door gegeven Pascal Thivent in het commentaar van de vraag

Ik weet echt niet deze praktijk aanbevelen (ook niet met behulp van versie varieert) ter wille van de build reproduceerbaarheid. Een build die begint plotseling uitvalt om een ​​onbekende reden is veel vervelender dan het handmatig aanpassen van een versienummer.

Ik zal dit soort praktijken adviseren:

<properties>
    <spring.version>3.1.2.RELEASE</spring.version>
</properties>

<dependencies>

    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-core</artifactId>
        <version>${spring.version}</version>
    </dependency>

    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-context</artifactId>
        <version>${spring.version}</version>
    </dependency>

</dependencies>

het is gemakkelijk te onderhouden en eenvoudig te debuggen. U kunt uw POM in een mum van tijd bij te werken.

antwoordde op 18/04/2018 om 09:10
bron van user

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more