streamalism.org

1. Introduktion

Opbygning af et softwareprojekt består typisk af opgaver som at downloade afhængigheder, lægge yderligere krukker på en klassesti, kompilere kildekode i binær kode, køre tests, pakke kompileret kode i implementerbare artefakter som JAR, WAR og ZIP-filer og implementere disse artefakter til en applikationsserver eller et lager.

Apache Maven automatiserer disse opgaver, minimerer risikoen for, at mennesker begår fejl, mens de bygger softwaren manuelt og adskiller arbejdet med at kompilere og pakke vores kode fra kodekonstruktionens.

I denne vejledning skal vi udforske dette kraftfulde værktøj til at beskrive, opbygge og styre Java-softwareprojekter ved hjælp af et centralt stykke information - Projektobjektmodel (POM) - der er skrevet i XML.

2. Hvorfor bruge Maven?

Nøglefunktionerne i Maven er:

• enkel projektopsætning, der følger bedste praksis: Maven forsøger at undgå så meget konfiguration som muligt ved at levere projektskabeloner (navngivet arketyper)
• afhængighedsstyring: det inkluderer automatisk opdatering, download og validering af kompatibilitet samt rapportering af afhængighedslukninger (også kendt som transitive afhængigheder)
• isolation mellem projektafhængigheder og plugins: med Maven hentes projektafhængigheder fra afhængighedsopbevaringssteder mens ethvert plugins afhængigheder hentes fra plugin repositories, hvilket resulterer i færre konflikter, når plugins begynder at downloade yderligere afhængigheder
• centralt arkivsystem: projektafhængigheder kan indlæses fra det lokale filsystem eller offentlige arkiver, såsom Maven Central

3. Projektobjektmodel

Konfigurationen af ​​et Maven-projekt udføres via en Projektobjektmodel (POM), repræsenteret af en pom.xml fil. Det POM beskriver projektet, administrerer afhængigheder og konfigurerer plugins til opbygning af softwaren.

Det POM definerer også forholdet mellem moduler i multimodulprojekter. Lad os se på den grundlæggende struktur for en typisk POM fil:

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

Lad os se nærmere på disse konstruktioner.

3.1. Projektidentifikatorer

Maven bruger et sæt identifikatorer, også kaldet koordinater, til entydigt at identificere et projekt og specificere, hvordan projektartefakten skal pakkes:

• groupId - et unikt basisnavn på det firma eller den gruppe, der oprettede projektet
• artefaktId - et unikt navn på projektet
• version - en version af projektet
• emballage - en emballeringsmetode (f.eks. KRIG/KRUKKE/ZIP)

De første tre af disse (groupId: artifactId: version) kombineres for at danne den unikke identifikator og er den mekanisme, hvormed du angiver, hvilke versioner af eksterne biblioteker (f.eks. JAR'er) dit projekt skal bruge.

3.2. Afhængigheder

Disse eksterne biblioteker, som et projekt bruger, kaldes afhængigheder. Afhængighedsstyringsfunktionen i Maven sikrer automatisk download af disse biblioteker fra et centralt arkiv, så du ikke behøver at gemme dem lokalt.

Dette er en nøglefunktion i Maven og giver følgende fordele:

• bruger mindre lagerplads ved betydeligt at reducere antallet af downloads fra fjernopbevaringssteder
• gør det hurtigere at tjekke et projekt
• giver en effektiv platform til udveksling af binære artefakter inden for din organisation og videre uden behov for at bygge artefakter fra kilden hver gang

For at erklære en afhængighed af et eksternt bibliotek skal du angive groupId, artefaktId, og version af biblioteket. Lad os se på et eksempel:

 org.springframework spring-core 4.3.5.RELEASE 

Når Maven behandler afhængighederne, downloader det Spring Core-biblioteket til dit lokale Maven-arkiv.

3.3. Opbevaringssteder

Et arkiv i Maven bruges til at opbygge artefakter og afhængigheder af forskellige typer. Standard lokalt lager er placeret i .m2 / lager mappe under brugerens hjemmekatalog.

Hvis en artefakt eller et plug-in er tilgængeligt i det lokale arkiv, bruger Maven det. Ellers downloades det fra et centralt lager og lagres i det lokale lager. Standard centrallager er Maven Central.

Nogle biblioteker, f.eks. JBoss-server, er ikke tilgængelige i det centrale lager, men er tilgængelige i et alternativt lager. For disse biblioteker skal du angive URL'en til det alternative lager inde pom.xml fil:

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

Bemærk, at du kan bruge flere arkiver i dine projekter.

3.4. Ejendomme

Brugerdefinerede egenskaber kan hjælpe med at lave din pom.xml fil lettere at læse og vedligeholde. I det klassiske brugssag bruger du brugerdefinerede egenskaber til at definere versioner til dit projekts afhængigheder.

Maven-ejendomme er værdi-pladsholdere og er tilgængelige overalt i en pom.xml ved hjælp af notationen $ {navn}, hvor navn er ejendommen.

Lad os se et eksempel:

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

Hvis du nu vil opgradere Spring til en nyere version, behøver du kun ændre værdien inde iegenskabskode og alle de afhængigheder, der bruger den egenskab i deres tags opdateres.

Egenskaber bruges ofte til at definere build sti-variabler:

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

3.5. Byg

Det bygge sektion er også en meget vigtig del af Maven POM. Det giver oplysninger om standard Maven mål, kataloget til det kompilerede projekt og det endelige navn på applikationen. Standardindstillingen bygge sektion ser sådan ud:

 installer $ {basedir} / target $ {artifactId} - $ {version} filtre / filter1.properties // ... 

Standardoutputmappen for kompilerede artefakter er navngivet mål, og det endelige navn på den pakkede artefakt består af artefaktId og version, men du kan ændre det når som helst.

3.6. Ved brug af Profiler

Et andet vigtigt træk ved Maven er dets støtte til profiler. EN profil er dybest set et sæt konfigurationsværdier. Ved hjælp af profiler, kan du tilpasse bygningen til forskellige miljøer såsom produktion / test / udvikling:

  produktion // ... udvikling sand // ... 

Som du kan se i eksemplet ovenfor, er standardprofilen indstillet til udvikling. Hvis du vil køre produktion profil, kan du bruge følgende Maven-kommando:

mvn ren installation -Produktion

4. Maven Build livscykler

Hver Maven-bygning følger en specificeret livscyklus. Du kan udføre flere build livscyklusmål, inklusive dem til udarbejde projektets kode, opret en pakke, og installere arkivfilen i det lokale Maven-afhængighedsregister.

4.1. Livscyklusfaser

Følgende liste viser den vigtigste Maven livscyklus faser:

• valider - kontrollerer rigtigheden af ​​projektet
• udarbejde - kompilerer den angivne kildekode til binære artefakter
• prøve - udfører enhedstest
• pakke - pakker kompileret kode i en arkivfil
• integration-test - udfører yderligere tests, der kræver emballagen
• verificere - kontrollerer om pakken er gyldig
• installere - installerer pakkefilen i det lokale Maven-lager
• indsætte - distribuerer pakkefilen til en ekstern server eller et lager

4.2. Plugins og Mål

En Maven plugin er en samling af en eller flere mål. Mål udføres i faser, hvilket hjælper med at bestemme rækkefølgen, i hvilken mål udføres.

Den rige liste over plugins, der officielt understøttes af Maven, er tilgængelig her. Der er også en interessant artikel, hvordan man bygger en eksekverbar KRUKKE på Baeldung ved hjælp af forskellige plugins.

For at få en bedre forståelse af hvilke mål køres i hvilke faser som standard, se på standard Maven livscyklus bindinger.

For at gennemgå en af ​​ovenstående faser er vi bare nødt til at kalde en kommando:

mvn 

For eksempel, mvn ren installation fjerner de tidligere oprettede jar / war / zip-filer og kompilerede klasser (ren) og udføre alle de faser, der er nødvendige for at installere nyt arkiv (installere).

Bemærk, at mål leveret af plugins kan associeres med forskellige faser af livscyklus.

5. Dit første Maven-projekt

I dette afsnit bruger vi kommandolinjefunktionaliteten i Maven til at oprette et Java-projekt.

5.1. Generering af et simpelt Java-projekt

For at opbygge et simpelt Java-projekt, lad os køre følgende kommando:

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

Det groupId er en parameter, der angiver den gruppe eller den person, der oprettede et projekt, som ofte er et omvendt virksomhedsdomænenavn. Det artefaktId er basispakkenavnet, der bruges i projektet, og vi bruger standarden arketype.

Da vi ikke specificerede versionen og emballagetypen, indstilles disse til standardværdier - versionen indstilles til 1.0-SNAPSHOT, og emballagen indstilles til krukke.

Hvis du ikke ved, hvilke parametre du skal angive, kan du altid angive interaktiv tilstand=rigtigt, så Maven beder om alle de krævede parametre.

Når kommandoen er afsluttet, har vi et Java-projekt, der indeholder et App.java klasse, som bare er et simpelt “Hello World” -program, i src / main / java folder.

Vi har også et eksempel på testklasse i src / test / java. Det pom.xml af dette projekt vil ligne dette:

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

Som du kan se, er junit afhængighed leveres som standard.

5.2. Kompilering og emballering af et projekt

Det næste trin er at kompilere projektet:

mvn kompilere

Maven vil løbe igennem alle livscyklus faser, der er nødvendige af udarbejde fase til opbygning af projektets kilder. Hvis du kun vil køre prøve fase, kan du bruge:

mvn test

Lad os påberåbe os pakke fase, der producerer det kompilerede arkiv krukke fil:

mvn-pakke

5.3. Udførelse af en applikation

Endelig skal vi udføre vores Java-projekt med exec-maven-plugin. Lad os konfigurere de nødvendige plugins i 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 

Det første plugin, maven-compiler-plugin, er ansvarlig for at kompilere kildekoden ved hjælp af Java version 1.8. Det exec-maven-plugin søger efter hovedklasse i vores projekt.

For at udføre applikationen kører vi følgende kommando:

mvn exec: java

6. Projekter med flere moduler

Mekanismen i Maven, der håndterer multimodulprojekter (også kaldet aggregator projekter) kaldes Reactor.

Det Reaktor samler alle tilgængelige moduler til at bygge, sorterer derefter projekter i den rigtige bygningsrækkefølge og til sidst bygger de dem en efter en.

Lad os se, hvordan man opretter et overordnet projekt med flere moduler.

6.1. Opret forældreprojekt

Først og fremmest er vi nødt til at oprette et overordnet projekt. For at oprette et nyt projekt med navnet forældre-projekt, vi bruger følgende kommando:

mvn arketype: generer -DgroupId = org.baeldung -DartifactId = overordnet-projekt

Dernæst opdaterer vi emballagetypen inde i pom.xml fil for at angive, at dette er en forælder modul:

pom

6.2. Opret delmodulprojekter

I det næste trin opretter vi submodulprojekter fra biblioteket forældre-projekt:

cd overordnet projekt mvn arketype: generer -DroupId = org.baeldung -DartifactId = kerne mvn arketype: generer -DroupId = org.baeldung -DartifactId = service mvn arketype: generer -DroupId = org.baeldung -DartifactId = webapp

For at kontrollere, om vi oprettede undermodulerne korrekt, ser vi i forældre-projekt pom.xml fil, hvor vi skal se tre moduler:

 webapp til kernetjeneste 

Desuden tilføjes en overordnet sektion i hver undermodul pom.xml:

 org.baeldung overordnet-projekt 1.0-SNAPSHOT 

6.3. Aktivér afhængighedsstyring i overordnet projekt

Afhængighedsstyring er en mekanisme til centralisering af afhængighedsinformation for et muti-modul forældreprojekt og dets børn.

Når du har et sæt projekter eller moduler, der arver en fælles forælder, kan du placere alle de krævede oplysninger om afhængighederne i det fælles pom.xml fil. Dette forenkler henvisningerne til artefakterne i barnet POMs.

Lad os se på en prøveforældres pom.xml:

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

Ved at erklære fjederkerne version i forældren, alle undermoduler, der afhænger af fjederkerne kan erklære afhængigheden ved kun at bruge groupId og artefaktId, og versionen arves:

  org.springframework spring-core // ... 

Desuden kan du give undtagelser for afhængighedsstyring hos forældrene pom.xml, så specifikke biblioteker ikke arves af underordnede moduler:

  org.springframework spring-context 

Endelig, hvis et underordnet modul skal bruge en anden version af en administreret afhængighed, kan du tilsidesætte den administrerede version i barnets pom.xml fil:

 org.springframework spring-core 4.2.1.RELEASE 

Bemærk, at mens underordnede moduler arver fra deres overordnede projekt, har et overordnet projekt ikke nødvendigvis nogen moduler, som det samler. På den anden side kan et overordnet projekt også samle projekter, der ikke arver fra det.

For yderligere information om arv og aggregering henvises til denne dokumentation.

6.4. Opdatering af undermodulerne og opbygning af et projekt

Vi kan ændre emballage type af hver undermodul. Lad os for eksempel ændre emballage af webapp modul til KRIG ved at opdatere pom.xml fil:

krig

Nu kan vi teste opbygningen af ​​vores projekt ved hjælp af mvn ren installation kommando. Outputtet fra Maven-logfiler skal svare til dette:

[INFO] Scanning efter projekter ... [INFO] Reaktor build-rækkefølge: [INFO] overordnet-projekt [INFO] kerne [INFO] -tjeneste [INFO] webapp // ............. [ INFO] ---------------------------------------- [INFO] Reaktorsammendrag: [ INFO] ----------------------------------------- [INFO] forældre-projekt. ................. SUCCESS [2.041s] [INFO] kerne ........................ .... SUCCESS [4.802s] [INFO] service ......................... SUCCESS [3.065s] [INFO] webapp ... ....................... SUCCES [6.125s] [INFO] ------------------- ----------------------

7. Konklusion

I denne artikel diskuterede vi nogle af de mere populære funktioner i Apache Maven build-værktøjet.

Alle kodeeksempler på Baeldung er bygget ved hjælp af Maven, så du nemt kan tjekke vores GitHub-projektwebsted for at se forskellige Maven-konfigurationer.