Apache Maven veiledning

1. Introduksjon

Å bygge et programvareprosjekt består vanligvis av oppgaver som nedlasting av avhengigheter, plassering av flere krukker på en klassebane, kompilering av kildekode til binær kode, kjøring av tester, pakking av kompilert kode i distribuerbare gjenstander som JAR, WAR og ZIP-filer og distribusjon av disse gjenstandene til en applikasjonsserver eller et lager.

Apache Maven automatiserer disse oppgavene, minimerer risikoen for at mennesker gjør feil mens de bygger programvaren manuelt og skiller arbeidet med å kompilere og pakke inn koden vår fra kodekonstruksjonen.

I denne veiledningen skal vi utforske dette kraftige verktøyet for å beskrive, bygge og administrere Java-programvareprosjekter ved hjelp av en sentral informasjon - Prosjektobjektmodell (POM) - som er skrevet i XML.

2. Hvorfor bruke Maven?

Hovedfunksjonene til Maven er:

  • enkelt prosjektoppsett som følger beste praksis: Maven prøver å unngå så mye konfigurasjon som mulig, ved å levere prosjektmaler (navngitt arketyper)
  • avhengighetsstyring: det inkluderer automatisk oppdatering, nedlasting og validering av kompatibiliteten, samt rapportering av avhengighetsnedleggelser (også kjent som transitive avhengigheter)
  • isolasjon mellom prosjektavhengigheter og plugins: med Maven blir prosjektavhengigheter hentet fra avhengighetsregister mens noen plugins avhengigheter blir hentet fra plugin-depoter, noe som resulterer i færre konflikter når plugins begynner å laste ned flere avhengigheter
  • sentralt arkivsystem: prosjektavhengigheter kan lastes inn fra det lokale filsystemet eller offentlige arkiver, for eksempel Maven Central
For å lære hvordan du installerer Maven på systemet ditt, kan du sjekke denne opplæringen på Baeldung.

3. Prosjektobjektmodell

Konfigurasjonen av et Maven-prosjekt gjøres via en Prosjektobjektmodell (POM), representert av en pom.xml fil. De POM beskriver prosjektet, administrerer avhengigheter, og konfigurerer plugins for å bygge programvaren.

De POM definerer også forholdet mellom moduler i flermodulprosjekter. La oss se på den grunnleggende strukturen til 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 // ... 

La oss se nærmere på disse konstruksjonene.

3.1. Prosjektidentifikatorer

Maven bruker et sett med identifikatorer, også kalt koordinater, for å identifisere et prosjekt unikt og spesifisere hvordan prosjektgjenstanden skal pakkes:

  • groupId - et unikt basenavn til selskapet eller gruppen som opprettet prosjektet
  • artefaktId - et unikt navn på prosjektet
  • versjon - en versjon av prosjektet
  • emballasje - en emballasjemetode (f.eks. KRIG/KRUKKE/glidelås)

De tre første av disse (groupId: artifactId: versjon) kombiner for å danne den unike identifikatoren og er mekanismen som du spesifiserer hvilke versjoner av eksterne biblioteker (f.eks. JAR) prosjektet ditt vil bruke.

3.2. Avhengigheter

Disse eksterne bibliotekene som et prosjekt bruker kalles avhengigheter. Avhengighetsstyringsfunksjonen i Maven sørger for automatisk nedlasting av disse bibliotekene fra et sentralt arkiv, slik at du ikke trenger å lagre dem lokalt.

Dette er en sentral funksjon i Maven og gir følgende fordeler:

  • bruker mindre lagringsplass ved å redusere antallet nedlastinger fra eksterne arkiver betydelig
  • gjør å sjekke ut et prosjekt raskere
  • gir en effektiv plattform for utveksling av binære gjenstander i organisasjonen din og utover uten behov for å bygge gjenstander fra kilden hver gang

For å kunne erklære en avhengighet av et eksternt bibliotek, må du oppgi groupId, artifactId, og versjon av biblioteket. La oss ta en titt på et eksempel:

 org.springframework spring-core 4.3.5.RELEASE 

Når Maven behandler avhengighetene, vil den laste ned Spring Core-biblioteket til ditt lokale Maven-arkiv.

3.3. Datalagre

Et depot i Maven brukes til å holde bygge gjenstander og avhengigheter av forskjellige typer. Standard lokalt depot er lokalisert i .m2 / depot mappen under brukerens hjemmekatalog.

Hvis en gjenstand eller en plugin er tilgjengelig i det lokale depotet, bruker Maven den. Ellers lastes den ned fra et sentralt depot og lagres i det lokale depotet. Standard sentrallager er Maven Central.

Noen biblioteker, for eksempel JBoss-server, er ikke tilgjengelige på det sentrale arkivet, men er tilgjengelig på et alternativt arkiv. For disse bibliotekene må du oppgi URL-en til det alternative depotet inne pom.xml fil:

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

Vær oppmerksom på at du kan bruke flere arkiver i prosjektene dine.

3.4. Eiendommer

Egendefinerte egenskaper kan være med på å lage din pom.xml fil lettere å lese og vedlikeholde. I den klassiske brukssaken vil du bruke egendefinerte egenskaper til å definere versjoner for prosjektets avhengighet.

Maven eiendommer er plassholdere med verdi og er tilgjengelige hvor som helst i en pom.xml ved å bruke notasjonen $ {name}, hvor Navn er eiendommen.

La oss se et eksempel:

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

Nå hvis du vil oppgradere Spring til en nyere versjon, trenger du bare å endre verdien ieiendomsmerke og alle avhengigheter som bruker eiendommen i deres tagger vil bli oppdatert.

Egenskaper brukes ofte til å definere variabler for byggesti:

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

3.5. Bygge

De bygge seksjonen er også en veldig viktig del av Maven POM. Den gir informasjon om standard Maven mål, katalogen for det kompilerte prosjektet, og det endelige navnet på applikasjonen. Standaren bygge delen ser slik ut:

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

Standard utgangsmappe for kompilerte gjenstander heter mål, og det endelige navnet på den pakkede gjenstanden består av artefaktId og versjon, men du kan endre det når som helst.

3.6. Ved hjelp av Profiler

Et annet viktig trekk ved Maven er støtten til profiler. EN profil er i utgangspunktet et sett med konfigurasjonsverdier. Ved bruk av profiler, kan du tilpasse bygningen for forskjellige miljøer, for eksempel produksjon / test / utvikling:

  produksjon // ... utvikling sant // ... 

Som du kan se i eksemplet ovenfor, er standardprofilen satt til utvikling. Hvis du vil kjøre produksjon profil, kan du bruke følgende Maven-kommando:

mvn ren installasjon -Produksjon

4. Maven Build Lifecycles

Hver Maven-bygning følger en spesifisert Livssyklus. Du kan utføre flere bygg Livssyklusmål, inkludert de til kompilere prosjektets kode, opprett en pakke, og installere arkivfilen i det lokale Maven avhengighetsregisteret.

4.1. Livssyklusfaser

Følgende liste viser den viktigste Maven Livssyklus faser:

  • validere - sjekker riktigheten av prosjektet
  • kompilere - kompilerer den oppgitte kildekoden til binære gjenstander
  • test - utfører enhetstester
  • pakke - pakker samlet kode i en arkivfil
  • integrasjonstest - utfører tilleggstester som krever emballasje
  • bekrefte - sjekker om pakken er gyldig
  • installere - installerer pakkefilen i det lokale Maven-depotet
  • utplassere - distribuerer pakkefilen til en ekstern server eller et lager

4.2. Plugins og Mål

En Maven plugg inn er en samling av en eller flere mål. Mål utføres i faser, noe som hjelper til med å bestemme rekkefølgen som mål blir henrettet.

Den rike listen over plugins som er offisielt støttet av Maven er tilgjengelig her. Det er også en interessant artikkel hvordan man bygger en kjørbar KRUKKE på Baeldung ved hjelp av forskjellige plugins.

For å få en bedre forståelse av hvilke mål kjøres i hvilke faser som standard, ta en titt på standard Maven Livssyklus bindinger.

For å gå gjennom en av de ovennevnte fasene, må vi bare ringe en kommando:

mvn 

For eksempel, mvn ren installasjon fjerner de tidligere opprettet jar / war / zip-filene og kompilerte klasser (ren) og utføre alle faser som er nødvendige for å installere nytt arkiv (installere).

Vær oppmerksom på at mål levert av plugins kan assosieres med forskjellige faser av Livssyklus.

5. Ditt første Maven-prosjekt

I denne delen vil vi bruke kommandolinjefunksjonaliteten til Maven til å lage et Java-prosjekt.

5.1. Generere et enkelt Java-prosjekt

For å bygge et enkelt Java-prosjekt, la oss kjøre følgende kommando:

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

De groupId er en parameter som indikerer gruppen eller individet som opprettet et prosjekt, som ofte er et omvendt domenenavn. De artefaktId er navnet på basispakken som brukes i prosjektet, og vi bruker standarden arketype.

Siden vi ikke spesifiserte versjonen og innpakningstypen, blir disse satt til standardverdier - versjonen vil bli satt til 1.0-STILLBILDE, og emballasjen blir satt til krukke.

Hvis du ikke vet hvilke parametere du skal oppgi, kan du alltid spesifisere interactiveMode=ekte, slik at Maven ber om alle nødvendige parametere.

Etter at kommandoen er fullført, har vi et Java-prosjekt som inneholder et App.java klasse, som bare er et enkelt “Hello World” -program, i src / main / java mappe.

Vi har også et eksempel på testklasse i src / test / java. De pom.xml av dette prosjektet vil se ut som 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 avhengighet er gitt som standard.

5.2. Kompilering og pakking av et prosjekt

Neste trinn er å kompilere prosjektet:

mvn kompilere

Maven vil løpe gjennom alle Livssyklus faser som trengs av kompilere fase for å bygge prosjektets kilder. Hvis du bare vil kjøre test fase, kan du bruke:

mvn test

La oss påkalle pakke fase, som vil produsere det kompilerte arkivet krukke fil:

mvn-pakke

5.3. Utføre en applikasjon

Til slutt skal vi gjennomføre Java-prosjektet vårt med exec-maven-plugin. La oss 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 

Den første pluginen, maven-compiler-plugin, er ansvarlig for å kompilere kildekoden ved hjelp av Java versjon 1.8. De exec-maven-plugin søker etter hovedklasse i prosjektet vårt.

For å utføre applikasjonen kjører vi følgende kommando:

mvn exec: java

6. Multimodulprosjekter

Mekanismen i Maven som håndterer multimodulprosjekter (også kalt aggregator prosjekter) kalles Reactor.

De Reaktor samler alle tilgjengelige moduler for å bygge, sorterer deretter prosjekter i riktig byggrekkefølge, og til slutt bygger de dem en etter en.

La oss se hvordan du lager et overordnet prosjekt med flere moduler.

6.1. Lag foreldreprosjekt

Først og fremst må vi lage et foreldreprosjekt. For å lage et nytt prosjekt med navnet foreldre-prosjekt, vi bruker følgende kommando:

mvn arketype: generer -DgroupId = org.baeldung -DartifactId = foreldre-prosjekt

Deretter oppdaterer vi innpakningstypen inne i pom.xml fil for å indikere at dette er en foreldre modul:

pom

6.2. Opprett submodule-prosjekter

I neste trinn lager vi submodulprosjekter fra katalogen til foreldre-prosjekt:

cd overordnet prosjekt mvn arketype: generer -DroupId = org.baeldung -DartifactId = kjerne mvn arketype: generer -DroupId = org.baeldung -DartifactId = tjeneste mvn arketype: generer -DgroupId = org.baeldung -DartifactId = webapp

For å verifisere om vi opprettet undermodulene riktig, ser vi i foreldre-prosjekt pom.xml fil, hvor vi skal se tre moduler:

 webapp for kjernetjeneste 

Videre vil en foreldreseksjon legges til i hver delmodul pom.xml:

 org.baeldung foreldre-prosjekt 1.0-SNAPSHOT 

6.3. Aktiver avhengighetsstyring i foreldreprosjektet

Avhengighetsstyring er en mekanisme for sentralisering av avhengighetsinformasjonen for et foreldreprosjekt med flere moduler og dets barn.

Når du har et sett med prosjekter eller moduler som arver en felles forelder, kan du legge all nødvendig informasjon om avhengighetene i det felles pom.xml fil. Dette vil forenkle referansene til gjenstandene i barnet POMs.

La oss ta en titt på en foreldres prøve pom.xml:

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

Ved å erklære vårkjernen versjon i foreldrene, alle undermoduler som er avhengig av vårkjernen kan erklære avhengigheten ved å bare bruke groupId og artefaktId, og versjonen blir arvet:

  org.springframework spring-core // ... 

Videre kan du tilby unntak for avhengighetsstyring hos foreldrene pom.xml, slik at spesifikke biblioteker ikke blir arvet av underordnede moduler:

  org.springframework vårkontekst 

Til slutt, hvis en underordnet modul trenger å bruke en annen versjon av en administrert avhengighet, kan du overstyre den administrerte versjonen i barnets pom.xml fil:

 org.springframework spring-core 4.2.1.RELEASE 

Vær oppmerksom på at mens underordnede moduler arver fra foreldreprosjektet, har ikke et overordnet prosjekt nødvendigvis noen moduler som det samler. På den annen side kan et overordnet prosjekt også samle prosjekter som ikke arver fra det.

For mer informasjon om arv og aggregering, se denne dokumentasjonen.

6.4. Oppdatere delmodulene og bygge et prosjekt

Vi kan endre emballasje type av hver undermodul. La oss for eksempel endre emballasje av webapp modul til KRIG ved å oppdatere pom.xml fil:

krig

Nå kan vi teste utbyggingen av prosjektet vårt ved å bruke mvn ren installasjon kommando. Utdataene fra Maven-loggene skal være lik dette:

[INFO] Skanner etter prosjekter ... [INFO] Reactor build order: [INFO] parent-project [INFO] core [INFO] service [INFO] webapp // ............. [ INFO] ----------------------------------------- [INFO] Reaktorsammendrag: [ INFO] ----------------------------------------- [INFO] foreldreprosjekt. ................. SUKSESS [2.041s] [INFO] kjerne ........................ .... SUCCESS [4.802s] [INFO] service ......................... SUKSESS [3.065s] [INFO] webapp ... ....................... SUKSESS [6.125s] [INFO] ------------------- ----------------------

7. Konklusjon

I denne artikkelen diskuterte vi noen av de mer populære funksjonene i Apache Maven-verktøyet.

Alle kodeeksempler på Baeldung er laget med Maven, slik at du enkelt kan sjekke GitHub-prosjektnettstedet for å se forskjellige Maven-konfigurasjoner.


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