Installeer een lokale pot met Maven

1. Het probleem en de opties

Maven is een zeer veelzijdige tool en de beschikbare openbare opslagplaatsen zijn ongeëvenaard. Er zal echter altijd een artefact zijn dat dat ook is nergens gehost, of de repository waar het wordt gehost is riskant om van afhankelijk te zijn, omdat het misschien niet beschikbaar is wanneer je het nodig hebt.

Als dat gebeurt, zijn er een paar keuzes:

  • bijt de kogel en installeer een volwaardige repository beheer oplossing zoals Nexus
  • probeer het artefact geüpload te krijgen naar een van de meer gerenommeerde openbare opslagplaatsen
  • installeer het artefact plaatselijk met behulp van een maven-plug-in

Nexus is natuurlijk de meer volwassen oplossing, maar het is ook hoe complexer. Het inrichten van een instantie om Nexus uit te voeren, Nexus zelf instellen, configureren en onderhouden kan overkill zijn voor zo'n eenvoudig probleem als het gebruik van een enkele jar. Als dit scenario - het hosten van aangepaste artefacten - echter gebruikelijk is, is een repositorymanager logisch.

Het artefact uploaden naar een openbare repository of in Maven central direct is ook een goede oplossing, maar meestal een langdurige. Bovendien is de bibliotheek mogelijk helemaal niet Maven ingeschakeld, wat het proces veel moeilijker maakt, dus het is geen realistische oplossing om het artefact NU te kunnen gebruiken.

Dat laat de derde optie over - het artefact toevoegen in bronbeheer en een maven-plug-in gebruiken - in dit geval de maven-install-plug-in om installeer het lokaal voordat het bouwproces het nodig heeft. Dit is verreweg de gemakkelijkste en meest betrouwbare optie die er is.

2. Installeer Local Jar met de maven-install-plugin

Laten we beginnen met de volledige configuratie die nodig is om het artefact in onze lokale repository te installeren:

 org.apache.maven.plugins maven-install-plugin 2.5.1 org.somegroup someartifact 1.0 jar $ {basedir} /dependencies/someartifact-1.0.jar true install-jar-lib install-file valideren 

Laten we nu de details van deze configuratie opsplitsen en analyseren.

2.1. De artefactinformatie

De Artefact-informatie wordt gedefinieerd als onderdeel van de element. De feitelijke syntaxis lijkt sterk op het declareren van de afhankelijkheid - a groupId, artefact-id en versie elementen.

Het volgende deel van de configuratie vereist het definiëren van het verpakking van het artefact - dit wordt gespecificeerd als pot.

Vervolgens moeten we het plaats van het werkelijke jar-bestand dat moet worden geïnstalleerd - dit kan een absoluut bestandspad zijn of het kan relatief zijn, met behulp van de woningen beschikbaar in Maven. In dit geval is het $ {basedir} eigenschap vertegenwoordigt de root van het project, namelijk de locatie waar het pom.xml Bestand bestaat. Dit betekent dat de someartifact-1.0.jar -bestand moet in een / afhankelijkheden / directory onder de root.

Ten slotte zijn er verschillende andere optionele details die ook kunnen worden geconfigureerd.

2.2. De executie

De uitvoering van de install-bestand doel is gebonden aan de valideren fase van de standaard Maven-buildlevenscyclus. Daarom moet u de validatiefase expliciet uitvoeren voordat u probeert te compileren:

mvn valideren

Na deze stap werkt de standaardcompilatie:

mvn schone installatie

Zodra de compilatiefase wordt uitgevoerd, wordt ons someartifact-1.0.jar correct is geïnstalleerd in onze lokale repository, net als elk ander artefact dat mogelijk is opgehaald uit Maven Central zelf.

2.3. Genereren van een POM vs Levering van de POM

De vraag of we een pom.xml bestand voor het artefact of niet hangt voornamelijk af van het runtime-afhankelijkheden van het artefact zelf. Simpel gezegd, als het artefact runtime-afhankelijkheden heeft van andere potten, moeten deze potten aanwezig zijn op het klassenpad ook tijdens runtime. Met een eenvoudig artefact dat geen probleem zou moeten zijn, aangezien het waarschijnlijk geen afhankelijkheden zal hebben tijdens runtime (een blad in de afhankelijkheidsgrafiek).

De GenereerPom optie in de install-bestand doel zou voldoende moeten zijn voor dit soort artefacten:

waar

Als het artefact echter complexer is en niet-triviaal afhankelijkheden, dan, als deze afhankelijkheden nog niet in het klassenpad staan, moeten ze worden toegevoegd. Een manier om dat te doen is door deze nieuwe afhankelijkheden handmatig te definiëren in het pom-bestand van het project. Een betere oplossing is om een ​​maatwerk te leveren pom.xml bestand samen met het geïnstalleerde artefact:

false $ {basedir} /dependencies/someartifact-1.0.pom

Hierdoor kan Maven alle afhankelijkheden oplossen van het artefact dat in deze gewoonte is gedefinieerd pom.xml, zonder ze handmatig te hoeven definiëren in het pom-hoofdbestand van het project.

3. Conclusie

Dit artikel gaat over het gebruik van een jar die nergens in een Maven-project wordt gehost door deze lokaal te installeren met de maven-install-plugin.


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