Multimodulprojekt med Maven

1. Oversigt

I denne vejledning viser vi, hvordan man bygger et multimodulprojekt med Maven.

Først vil vi diskutere, hvad der er et multimodulprojekt og se på fordelene ved at følge denne tilgang. Derefter opretter vi vores prøveprojekt. For en god introduktion til Maven, se denne vejledning.

2. Mavens multimodulprojekt

Et multimodulprojekt er bygget fra en aggregator POM, der administrerer en gruppe af submodules. I de fleste tilfælde er aggregatoren placeret i projektets rodkatalog og skal have emballage af typen pom.

Nu er submodulerne regelmæssige Maven-projekter, og de kan bygges separat eller gennem aggregator POM.

Ved at bygge projektet gennem aggregatoren POM, er hvert projekt, der har en anden emballagetype end pom vil resultere i en indbygget arkivfil.

3. Fordele ved at bruge multimoduler

Den væsentlige fordel ved at bruge denne fremgangsmåde er, at vi kan reducere dobbeltarbejde.

Lad os sige, at vi har en applikation, der består af flere moduler, lad det være et front-end-modul og et back-end-modul. Nu arbejder vi på dem begge og ændrer funktionalitet, som påvirker de to. I så fald skal vi uden et specialbygget værktøj bygge begge komponenter separat eller skrive et script, der kompilerer koden, kører tests og viser resultaterne. Derefter, efter at vi har fået endnu flere moduler i projektet, bliver det sværere at styre og vedligeholde.

Derudover kan projekter muligvis have brug for visse Maven-plugins i den virkelige verden for at udføre forskellige operationer under byggets livscyklus, dele afhængigheder og profiler eller inkludere andre BOM-projekter.

Derfor kan vi, når vi udnytter multimoduler opbygge vores applikations moduler i en enkelt kommando og hvis ordren betyder noget, vil Maven finde ud af det for os. Det kan vi også dele en stor mængde konfiguration med andre moduler.

4. Forældres POM

Maven støtter arv på en måde, der hver pom.xml-fil har den implicitte forælder POM, den hedder Super POM og kan findes i Maven-binærfiler. Disse to filer flettes af Maven og danner den effektive POM.

Derfor kan vi skabe vores egen pom.xml-fil, der tjener os som det overordnede projekt. Derefter kan vi inkludere der alle konfigurationer med afhængigheder og indstille dette som forælder til vores barnemoduler, så de arver fra det.

Udover arven giver Maven forestillingen om sammenlægning. Forældre-POM, der udnytter denne funktionalitet, kaldes en samlet POM. Dybest set denne form for POM erklærer sine moduler eksplicit i sin pom.xml-fil.

5. Undermoduler

Undermoduler eller underprojekter er regelmæssige Maven-projekter, der arver fra forældrenes POM. Som vi allerede ved, lad os dele konfiguration og afhængigheder med undermoduler. Men hvis vi gerne vil bygge eller frigive vores projekt i et skud, er vi nødt til at erklære vores undermoduler eksplicit i forælder-POM. I sidste ende vil vores forældres POM være forælder såvel som den samlede POM.

6. Opbygning af applikationen

Nu hvor vi forstår Mavens undermoduler og hierarki, lad os bygge en prøveapplikation for at demonstrere dem. Vi bruger Mavens kommandolinjegrænseflade til at generere vores projekter.

Denne app vil bestå af tre moduler, der repræsenterer:

  • Det kerne del af vores domæne
  • Et web service leverer nogle REST API'er
  • EN webapp indeholdende brugervenlige webaktiver af en slags

Da vi fokuserer på Maven, forbliver implementeringen af ​​disse tjenester udefineret.

6.1. Genererer forældre-POM

Lad os først oprette et overordnet projekt:

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

Når forældrene er genereret, skal vi åbne pom.xml fil, der er placeret i forældrenes bibliotek, og skift emballagen til pom.

pom

Ved at indstille emballage til pom-type erklærer vi, at projektet fungerer som forælder eller en samler - det producerer ikke yderligere artefakter.

Nu, når vores aggregator er færdig, kan vi generere vores undermoduler.

Vi skal dog bemærke, at dette er stedet, hvor al konfiguration, der skal deles, er placeret og til sidst genbruges i underordnede moduler. Blandt andet kan vi gøre brug af afhængighedLedelse eller pluginManagement her.

6.2. Oprettelse af undermoduler

Som vores forælder blev POM navngivet forældre-projekt, skal vi sørge for, at vi er i forældrenes bibliotek og kører frembringe kommandoer:

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

Bemærk den anvendte kommando. Det er det samme som vi brugte for forældrene. Sagen her er, at disse moduler er regelmæssige Maven-projekter, men alligevel anerkendte Maven, at de er indlejrede. Da vi ændrede biblioteket til forældre-projekt, fandt det, at forælder har emballage af typen pom og modificerede begge pom.xml filer i overensstemmelse hermed.

Derefter vil Maven generere tre undermoduler og ændre forældrenes for os pom.xml fil ved at tilføje nogle tags:

 webapp til kernetjeneste 

Nu erklærer vores forælder udtrykkeligt aggregerede moduler.

Næste, når du kører mvn-pakke kommando i det overordnede projektkatalog, vil Maven opbygge og teste alle tre moduler.

Desuden vil Maven Reactor analysere vores projekt og bygge det i korrekt rækkefølge. Så hvis vores webapp modul afhænger af servicen modul, vil Maven først bygge service, derefter webapp.

Når alt kommer til alt, hvis vi ønsker at dele al konfiguration med vores undermoduler i deres pom.xml filer, bliver vi nødt til at erklære forælderen:

 org.baeldung overordnet-projekt 1.0-SNAPSHOT 

Vi skal bemærke, at undermoduler kun kan have en forælder. Vi kan dog importere mange styklister. Flere detaljer om BOM-filerne kan findes i denne artikel.

6.3. Opbygning af projektet

Nu kan vi bygge alle tre moduler på én gang. I forældrenes projektmappe skal du køre:

mvn-pakke

Dette bygger alle modulerne, vi skal se følgende output af kommandoen:

[INFO] Scanning efter projekter ... [INFO] -------------------------------------- ---------------------------------- [INFO] Reactor Build Order: [INFO] overordnet projekt [INFO] core [INFO] -tjeneste [INFO] webapp ... [INFO] Reaktorsammendrag: [INFO] overordnet projekt .......................... ........... SUCCESS [0.140 s] [INFO] kerne .............................. ................. SUCCESS [2.195 s] [INFO] service ........................ .................... SUCCESS [0.767 s] [INFO] webapp ..................... ........................ SUCCES [0.572 s] [INFO] ------------------ -------------------------------------------------- ---- [INFO] BYG SUCCES [INFO] -------------------------------------- ----------------------------------

Reaktoren viser listen forældre-projekt, men som det er pom skriv det er ekskluderet, og build-resultaterne i tre separate .krukke filer til alle andre moduler. I så fald forekommer build i tre af dem.

7. Konklusion

I denne vejledning diskuterede vi fordelene ved at bruge Maven multimoduler. Vi skelner også mellem almindelig Mavens forælder POM og samlet POM. Til sidst viste vi, hvordan man opretter et simpelt multimodul til at begynde at lege med.

Maven er et godt værktøj, men det er komplekst alene. Hvis du gerne vil finde flere detaljer om Maven, skal du kigge på Sonatype Maven-referencen eller Apache Maven-guiderne. Hvis du søger avancerede anvendelser af Maven-multimoduler, der er oprettet, skal du se, hvordan Spring Boot-projektet udnytter brugen af ​​det.

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.


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