streamalism.org

1. Inleiding

Het bouwen van een softwareproject bestaat doorgaans uit taken als het downloaden van afhankelijkheden, het plaatsen van extra jars op een klassenpad, het compileren van broncode in binaire code, het uitvoeren van tests, het verpakken van gecompileerde code in implementeerbare artefacten zoals JAR-, WAR- en ZIP-bestanden, en het implementeren van deze artefacten naar een applicatieserver of repository.

Apache Maven automatiseert deze taken, waardoor het risico dat mensen fouten maken tijdens het handmatig bouwen van de software wordt geminimaliseerd en het werk van het compileren en verpakken van onze code wordt gescheiden van dat van codeconstructie.

In deze tutorial gaan we deze krachtige tool verkennen voor het beschrijven, bouwen en beheren van Java-softwareprojecten met behulp van een centraal stuk informatie - de Project Object Model (POM) - dat is geschreven in XML.

2. Waarom Maven gebruiken?

De belangrijkste kenmerken van Maven zijn:

• eenvoudige projectconfiguratie volgens best practices: Maven probeert zoveel mogelijk configuratie te vermijden door projectsjablonen (named archetypen)
• afhankelijkheidsbeheer: het omvat het automatisch bijwerken, downloaden en valideren van de compatibiliteit, evenals het rapporteren van de afhankelijkheidssluitingen (ook bekend als transitieve afhankelijkheden)
• isolatie tussen projectafhankelijkheden en plug-ins: met Maven worden projectafhankelijkheden opgehaald uit het afhankelijkheidsopslagplaatsen terwijl de afhankelijkheden van een plug-in worden opgehaald uit het plug-in opslagplaatsen, wat resulteert in minder conflicten wanneer plug-ins aanvullende afhankelijkheden beginnen te downloaden
• centraal repository-systeem: projectafhankelijkheden kunnen worden geladen vanuit het lokale bestandssysteem of openbare opslagplaatsen, zoals Maven Central

3. Projectobjectmodel

De configuratie van een Maven-project gebeurt via een Project Object Model (POM), vertegenwoordigd door een pom.xml het dossier. De POM beschrijft het project, beheert afhankelijkheden en configureert plug-ins voor het bouwen van de software.

De POM definieert ook de relaties tussen modules van projecten met meerdere modules. Laten we eens kijken naar de basisstructuur van een typische POM het dossier:

 4.0.0 org.baeldung org.baeldung jar 1.0-SNAPSHOT org.baeldung //maven.apache.org junit junit 4.12 test // ... 

Laten we deze constructies eens nader bekijken.

3.1. Project-ID's

Maven gebruikt een set identificatiegegevens, ook wel coördinaten genoemd, om een ​​project uniek te identificeren en te specificeren hoe het projectartefact moet worden verpakt:

• groupId - een unieke basisnaam van het bedrijf of de groep die het project heeft gemaakt
• artefact-id - een unieke naam van het project
• versie - een versie van het project
• verpakking - een verpakkingsmethode (bijv. OORLOG/POT/ZIP)

De eerste drie hiervan (groupId: artifactId: version) combineren om de unieke identificatie te vormen en zijn het mechanisme waarmee u specificeert welke versies van externe bibliotheken (bijv.JAR's) uw project zal gebruiken.

3.2. Afhankelijkheden

Deze externe bibliotheken die een project gebruikt, worden afhankelijkheden genoemd. De afhankelijkheidsbeheerfunctie in Maven zorgt ervoor dat die bibliotheken automatisch worden gedownload vanuit een centrale opslagplaats, zodat u ze niet lokaal hoeft op te slaan.

Dit is een belangrijk kenmerk van Maven en biedt de volgende voordelen:

• gebruikt minder opslagruimte door het aantal downloads van externe opslagplaatsen aanzienlijk te verminderen
• maakt het afrekenen van een project sneller
• biedt een effectief platform voor het uitwisselen van binaire artefacten binnen uw organisatie en daarbuiten zonder dat u elke keer artefacten uit de bron hoeft te bouwen

Om een ​​afhankelijkheid van een externe bibliotheek aan te geven, moet u het groupId, artefactId, en de versie van de bibliotheek. Laten we een voorbeeld bekijken:

 org.springframework spring-core 4.3.5.RELEASE 

Terwijl Maven de afhankelijkheden verwerkt, wordt de Spring Core-bibliotheek gedownload naar uw lokale Maven-repository.

3.3. Opslagplaatsen

Een repository in Maven wordt gebruikt om build-artefacten en afhankelijkheden van verschillende typen te bewaren. De standaard lokale repository bevindt zich in het .m2 / repository map onder de homedirectory van de gebruiker.

Als een artefact of een plug-in beschikbaar is in de lokale repository, gebruikt Maven deze. Anders wordt het gedownload vanuit een centrale repository en opgeslagen in de lokale repository. De standaard centrale opslagplaats is Maven Central.

Sommige bibliotheken, zoals de JBoss-server, zijn niet beschikbaar op de centrale opslagplaats, maar zijn beschikbaar op een alternatieve opslagplaats. Voor die bibliotheken moet u de URL naar de alternatieve repository binnenin opgeven pom.xml het dossier:

  JBoss-opslagplaats //repository.jboss.org/nexus/content/groups/public/ 

Houd er rekening mee dat u meerdere repositories in uw projecten kunt gebruiken.

3.4. Eigendommen

Aangepaste eigenschappen kunnen helpen om uw pom.xml bestand gemakkelijker te lezen en te onderhouden. In het klassieke gebruik zou u aangepaste eigenschappen gebruiken om versies voor de afhankelijkheden van uw project te definiëren.

Maven-eigenschappen zijn tijdelijke aanduidingen voor waarde en zijn overal binnen een pom.xml door de notatie te gebruiken $ {naam}, waar naam is het eigendom.

Laten we een voorbeeld bekijken:

 4.3.5.RELEASE org.springframework spring-core $ {spring.version} org.springframework spring-context $ {spring.version} 

Als u Spring nu wilt upgraden naar een nieuwere versie, hoeft u alleen de waarde in hetproperty-tag en alle afhankelijkheden die die eigenschap gebruiken in hun tags worden bijgewerkt.

Eigenschappen worden ook vaak gebruikt om buildpadvariabelen te definiëren:

 $ {project.build.directory} / tmp / // ... $ {project.resources.build.folder} // ... 

3.5. Bouwen

De bouwen sectie is ook een zeer belangrijk deel van de Maven POM. Het geeft informatie over de standaard Maven doel, de directory voor het gecompileerde project en de uiteindelijke naam van de applicatie. De standaard bouwen sectie ziet er als volgt uit:

 installeer $ {basedir} / target $ {artifactId} - $ {version} filters / filter1.properties // ... 

De standaard uitvoermap voor gecompileerde artefacten heeft de naam doelwiten de uiteindelijke naam van het verpakte artefact bestaat uit de artefact-id en versie, maar u kunt dit op elk moment wijzigen.

3.6. Gebruik makend van Profielen

Een ander belangrijk kenmerk van Maven is de ondersteuning voor profielen. EEN profiel is in feite een set configuratiewaarden. Door het gebruiken van profielen, kunt u de build aanpassen voor verschillende omgevingen, zoals Productie / Test / Ontwikkeling:

  productie // ... ontwikkeling waar // ... 

Zoals u in het bovenstaande voorbeeld kunt zien, is het standaardprofiel ingesteld op ontwikkeling. Als u het productie profiel, kunt u de volgende Maven-opdracht gebruiken:

mvn schone installatie -Pproduction

4. Maven Build levenscycli

Elke Maven-build volgt een opgegeven levenscyclus. U kunt verschillende build levenscyclusdoelen, inclusief degenen tot compileren de projectcode, maak een pakket, en installeren het archiefbestand in de lokale Maven-afhankelijkheidsrepository.

4.1. Levenscyclusfasen

De volgende lijst toont de belangrijkste Maven levenscyclus fasen:

• valideren - controleert de juistheid van het project
• compileren - compileert de verstrekte broncode in binaire artefacten
• test - voert unit tests uit
• pakket - verpakt gecompileerde code in een archiefbestand
• integratietest - voert aanvullende tests uit, waarvoor de verpakking nodig is
• verifiëren - controleert of het pakket geldig is
• installeren - installeert het pakketbestand in de lokale Maven-repository
• inzetten - implementeert het pakketbestand op een externe server of opslagplaats

4.2. Plug-ins en Doelen

Een maven inpluggen is een verzameling van een of meer doelen. Doelen worden in fasen uitgevoerd, wat helpt bij het bepalen van de volgorde waarin de doelen worden uitgevoerd.

De uitgebreide lijst met plug-ins die officieel worden ondersteund door Maven, is hier beschikbaar. Er is ook een interessant artikel over het bouwen van een uitvoerbaar bestand POT op Baeldung met behulp van verschillende plug-ins.

Om een ​​beter begrip te krijgen van welke doelen worden standaard in welke fasen uitgevoerd, kijk eens naar de standaard Maven levenscyclus bindingen.

Om een ​​van de bovenstaande fasen te doorlopen, hoeven we slechts één commando te bellen:

mvn 

Bijvoorbeeld, mvn schone installatie verwijdert de eerder gemaakte jar / war / zip-bestanden en gecompileerde klassen (schoon) en voer alle fasen uit die nodig zijn om een ​​nieuw archief te installeren (installeren).

Houd er rekening mee dat doelen geleverd door plug-ins kan worden geassocieerd met verschillende fasen van de levenscyclus.

5. Je eerste Maven-project

In deze sectie zullen we de opdrachtregelfunctionaliteit van Maven gebruiken om een ​​Java-project te maken.

5.1. Een eenvoudig Java-project genereren

Laten we de volgende opdracht uitvoeren om een ​​eenvoudig Java-project te bouwen:

mvn-archetype: genereer -DgroupId = org.baeldung -DartifactId = org.baeldung.java -DarchetypeArtifactId = maven-archetype-quickstart -DinteractiveMode = false

De groupId is een parameter die de groep of het individu aangeeft die een project heeft gemaakt, wat vaak een omgekeerde bedrijfsdomeinnaam is. De artefact-id is de basispakketnaam die in het project wordt gebruikt, en we gebruiken de standaard archetype.

Omdat we de versie en het verpakkingstype niet hebben gespecificeerd, worden deze op de standaardwaarden ingesteld - de versie wordt ingesteld op 1.0-SNAPSHOT, en de verpakking wordt ingesteld op pot.

Als u niet weet welke parameters u moet opgeven, kunt u dit altijd specificeren interactiveMode=waar, zodat Maven om alle vereiste parameters vraagt.

Nadat de opdracht is voltooid, hebben we een Java-project met een App.java class, wat gewoon een eenvoudig "Hello World" -programma is, in het src / main / java map.

We hebben ook een voorbeeldtestles in src / test / java. De pom.xml van dit project ziet er ongeveer zo uit:

 4.0.0 org.baeldung org.baeldung.java jar 1.0-SNAPSHOT org.baeldung.java //maven.apache.org junit junit 4.1.2 test 

Zoals u kunt zien, is de junit afhankelijkheid wordt standaard geleverd.

5.2. Een project samenstellen en verpakken

De volgende stap is om het project te compileren:

mvn compileren

Maven zal alles doornemen levenscyclus fasen die nodig zijn voor de compileren fase om de bronnen van het project te bouwen. Als u alleen het test fase kunt u gebruiken:

mvn-test

Laten we nu het pakket fase, die het gecompileerde archief zal produceren pot het dossier:

mvn-pakket

5.3. Een applicatie uitvoeren

Ten slotte gaan we ons Java-project uitvoeren met de exec-maven-plugin. Laten we de benodigde plug-ins configureren in het pom.xml:

 src maven-compiler-plugin 3.6.1 1.8 1.8 org.codehaus.mojo exec-maven-plugin 1.5.0 org.baeldung.java.App 

De eerste plug-in, maven-compiler-plugin, is verantwoordelijk voor het compileren van de broncode met Java versie 1.8. De exec-maven-plugin zoekt naar het mainClass in ons project.

Om de applicatie uit te voeren, voeren we de volgende opdracht uit:

mvn exec: java

6. Multi-module projecten

Het mechanisme in Maven dat projecten met meerdere modules afhandelt (ook wel aggregator projects) wordt genoemd Reactor.

De Reactor verzamelt alle beschikbare modules om te bouwen, sorteert vervolgens projecten in de juiste bouwvolgorde en bouwt ze ten slotte een voor een op.

Laten we eens kijken hoe we een bovenliggend project met meerdere modules kunnen maken.

6.1. Creëer bovenliggend project

Allereerst moeten we een ouderproject maken. Om een ​​nieuw project met de naam aan te maken ouder-project, we gebruiken het volgende commando:

mvn-archetype: genereer -DgroupId = org.baeldung -DartifactId = bovenliggend project

Vervolgens werken we het verpakkingstype in het pom.xml bestand om aan te geven dat dit een ouder module:

pom

6.2. Maak submodule-projecten

In de volgende stap maken we submoduleprojecten aan vanuit de directory van ouder-project:

cd ouder-project mvn-archetype: genereren -DgroupId = org.baeldung -DartifactId = kern mvn-archetype: genereren -DgroupId = org.baeldung -DartifactId = service mvn-archetype: genereren -DgroupId = org.baeldung -DartifactId = webapp

Om te controleren of we de submodules correct hebben gemaakt, kijken we in het bovenliggend project pom.xml bestand, waar we drie modules zouden moeten zien:

 kernservice webapp 

Bovendien wordt in elke submodule een bovenliggende sectie toegevoegd pom.xml:

 org.baeldung bovenliggend project 1.0-SNAPSHOT 

6.3. Schakel afhankelijkheidsbeheer in het bovenliggende project in

Afhankelijkheidsbeheer is een mechanisme voor het centraliseren van de afhankelijkheidsinformatie voor een muti-module bovenliggend project en zijn onderliggende projecten.

Als u een set projecten of modules heeft die een gemeenschappelijke ouder erven, kunt u alle vereiste informatie over de afhankelijkheden in de gemeenschappelijke map plaatsen. pom.xml het dossier. Dit vereenvoudigt de verwijzingen naar de artefacten in het kind POMs.

Laten we eens kijken naar een voorbeeld van een ouder pom.xml:

   org.springframework spring-core 4.3.5.RELEASE // ... 

Door het lente-kern versie in de bovenliggende versie, alle submodules die afhankelijk zijn van lente-kern kan de afhankelijkheid declareren met alleen de groupId en artefact-id, en de versie zal worden overgenomen:

  org.springframework spring-core // ... 

Bovendien kunt u uitsluitingen opgeven voor afhankelijkheidsbeheer bij ouders pom.xml, zodat specifieke bibliotheken niet worden overgenomen door onderliggende modules:

  org.springframework spring-context 

Ten slotte, als een onderliggende module een andere versie van een beheerde afhankelijkheid moet gebruiken, kunt u de beheerde versie in de onderliggende pom.xml het dossier:

 org.springframework spring-core 4.2.1.RELEASE 

Houd er rekening mee dat hoewel onderliggende modules van hun bovenliggende project erven, een bovenliggend project niet noodzakelijkerwijs modules heeft die het aggregeert. Aan de andere kant kan een ouderproject ook projecten samenvoegen die er niet van erven.

Raadpleeg deze documentatie voor meer informatie over overerving en aggregatie.

6.4. De submodules bijwerken en een project bouwen

We kunnen de verpakking type van elke submodule. Laten we bijvoorbeeld het verpakking van de web applicatie module naar OORLOG door het pom.xml het dossier:

oorlog

Nu kunnen we de build van ons project testen met behulp van de mvn schone installatie opdracht. De uitvoer van de Maven-logboeken zou er ongeveer zo uit moeten zien:

[INFO] Scannen naar projecten ... [INFO] Reactor bouwopdracht: [INFO] ouderproject [INFO] kern [INFO] service [INFO] webapp // ............. [ INFO] ----------------------------------------- [INFO] Samenvatting reactor: [ INFO] ----------------------------------------- [INFO] bovenliggend project. ................. SUCCES [2.041s] [INFO] kern ........................ .... SUCCES [4.802s] [INFO] service ......................... SUCCES [3.065s] [INFO] webapp ... ....................... SUCCES [6.125s] [INFO] ------------------- ----------------------

7. Conclusie

In dit artikel hebben we enkele van de meer populaire functies van de Apache Maven-buildtool besproken.

Alle codevoorbeelden op Baeldung zijn gebouwd met behulp van Maven, dus u kunt eenvoudig onze GitHub-projectwebsite bezoeken om verschillende Maven-configuraties te zien.