At bygge et projekt er en kompleks forretning. På grund af de snesevis af opgaver, der kræves for at konvertere din hodge-podge af filer til et arbejdsprogram, findes der bogstaveligt talt hundredvis af værktøjer, der gør alt fra generering af kildekode, til kompilering, test, distribution, til brygning af morgenkaffe du finder en, kære læser, lad mig det vide). Mange af disse programmer er fremragende til hvad de gør. Desværre er der sjældent meget fælles for dem af os, der administrerer store byggesystemer til at leve af; hvert program kræver sin egen forskellige installation og esoteriske konfiguration. Det er blevet en uundgåelig kendsgerning i vores liv, at størstedelen af byggesystemerne er specialbygget ved håndlimning af disse værktøjer med flere homebrew-scripts (ja, Ant-scripts tæller).
Mere end et andet byggeværktøj er Maven en build ramme. Det adskiller din kode rent fra konfigurationsfiler, dokumentation og afhængigheder. Maven er overraskende fleksibel med at lade brugerne konfigurere de fleste aspekter af deres kode såvel som til at kontrollere adfærden for plug-ins, individuelle mål og endda selve build-livscyklussen. Maven er den egentlige struktur, og inden for disse mure bor dit projekt; det ønsker at være en imødekommende vært.
Men problemet er stadig: at styre arbejdet med tusindvis af brugerdefinerede build-scripts inden for en enkelt ramme er hårdt og for at blive gjort korrekt kræver det meget information. Heldigvis har Maven 2-teamet været ret succesfuldt. At lære af Maven 1's fejl, utallige brugeranmodninger, tilpasning og opdatering, er Maven 2 mere kraftfuld end nogensinde. Desværre kommer stor konfiguration med stor kraft. For at Maven 2-artefakter skal være let bærbare enheder, falder den komplekse konfiguration i en enkelt fil. Gå ind i Maven POM.
Hvad er POM?
POM står for projektobjektmodel. Det er en XML-repræsentation af et Maven-projekt, der opbevares i en fil med navnet pom.xml. I nærværelse af Maven-folk taler det om et projekt i filosofisk forstand ud over en simpel samling af filer, der indeholder kode. Et projekt indeholder konfigurationsfiler såvel som involverede udviklere og roller, de spiller, system til manglende sporing, organisation og licenser, URL'en, hvor projektet bor, projektets afhængighed og alle de andre små stykker, der kommer i spil for at give kode liv. Et projekt er en one-stop-shop for alle ting, der er relateret til det. Faktisk i Maven-verdenen behøver et projekt slet ikke indeholde nogen kode, blot en pom.xml. Vi vil støde på et par sådanne typer projekter senere i artiklen.
Et hurtigt strukturelt overblik
POM er stor og kompleks, så at bryde den i stykker letter fordøjelsen. Med henblik på denne diskussion grupperes disse stykker i fire logiske enheder, som vist i figur 1: POM-forhold, projektinformation, byggeindstillinger og byggemiljø. Vi begynder med at diskutere POM-forhold.
Nedenfor er en liste over elementerne direkte under POM's projektelement. Læg mærke til det modelVersion indeholder 4.0.0. Det er i øjeblikket den eneste understøttede POM-version til Maven 2 og er altid påkrævet. Maven 4.0.0 XML-skemadefinitionen findes på //maven.apache.org/maven-v4_0_0.xsd. Dens øverste elementer er som følger:
4.0.0
... ... ... ... ... ... ...
... ... ... ... ... ... ... ...
... ... ... ...
... ... ... ...
... ... ... ... ...
POM-forhold
Vores første forretningsorden er at undersøge projektforhold, repræsenteret i figur 2 som det øverste venstre hjørne af diagrammet i figur 1.
Projekter skal på en eller anden måde forholde sig til hinanden. Siden oprettelsen af de første samlere har softwareprojekter haft afhængigheder; Maven har introduceret flere former for relationer hidtil ubrugt i en sådan form til Java-projekter. Disse forhold er Maven-koordinater, koordinatbaserede afhængigheder, projektarv og aggregering.
Koordinater
Hvert Maven-projekt indeholder sin egen unikke identifikator, der kaldes projektets koordinater, der fungerer som en artefaktadresse, hvilket giver den et unikt sted i Maven-universet. Hvis projekter ikke havde nogen måde at forholde sig til hinanden, ville det ikke være nødvendigt med koordinater. Det vil sige, hvis et univers kun havde et hus, hvorfor skulle det have brug for en adresse som Cherrywood Lane 315?
Koden nedenfor er den minimale POM, som Maven 2 tillader -, og er alle obligatoriske felter. De fungerer som en vektor i Maven-rummet med elementerne grouper, identifikator og tidsstempel.
4.0.0org.codehaus.mojo-en1I Maven-verdenen udgør disse tre hovedelementer (Maven-treenigheden - se dens herlighed!) En POM's koordinater. Koordinaterne er repræsenteret ved figur 3.
Måske er denne POM ikke i sig selv så imponerende. Det bliver bedre.
Afhængigheder
Et af de mest magtfulde aspekter af Maven er dets håndtering af projektafhængigheder, og i Maven 2 inkluderer det transitive afhængigheder. Figur 4 illustrerer, hvordan vi skal repræsentere dem grafisk.
Afhængighedsstyring har en lang tradition for at være et kompliceret rod til alt andet end det mest trivielle af projekter. "Jarmageddon" følger hurtigt, når afhængighedstræet bliver enormt, kompliceret og pinligt for arkitekter, der bliver hånet af nyuddannede, der "helt kunne have gjort det bedre." "Jar Hell" følger, hvor versioner af afhængigheder på et system ikke er helt de samme versioner som dem, der blev brugt til udvikling; de har enten den forkerte version eller modstridende versioner mellem lignende navngivne JAR'er. Derfor begynder tingene at gå i stykker og finde ud af, hvorfor det viser sig at være svært. Maven løser begge disse problemer ved at have et fælles lokalt arkiv, hvorfra man kan linke til de korrekte projekter, versioner og alt.
Arv
En af de funktioner, som Maven 2 bringer fra Maven 1 dage, er projektarv, som repræsenteret i figur 5. I byggesystemer, såsom Ant, kan arv bestemt simuleres, men Maven har taget det ekstra skridt i at gøre projektarv eksplicit til projektets objektmodel.
Følgende kode definerer en overordnet POM i Maven 2:
4.0.0org.codehaus.mojob2pomDenne forælder ligner vores første POM med en mindre forskel. Bemærk, at vi har indstillet emballage skriv som pom, som er påkrævet for både overordnede og samleprojekter (vi vil dække mere om emballage i afsnittet "Bygningsindstillinger"). Hvis vi vil bruge ovenstående projekt som forælder, kan vi ændre projektet org.codehaus.mojo: a POM skal være:
4.0.0org.codehaus.mojob2-enDet er vigtigt at bemærke, at alle POM'er arver fra en forælder, uanset om de er udtrykkeligt defineret eller ej. Denne basis-POM er kendt som "super POM" og indeholder værdier, der er arvet som standard. En nem måde at se på standardkonfigurationerne af super POM er ved at oprette en simpel pom.xml uden andet end modelVersion, groupId, artefaktIdog versionog kører kommandoen mvn hjælp: effektiv-pom.
Ud over blot at indstille værdier, der skal arves, har forældre også beføjelse til at oprette standardkonfigurationer for deres børn uden faktisk at påføre dem værdier. Afhængighedsstyring er et særligt kraftfuldt instrument til konfiguration af et sæt afhængigheder gennem en fælles placering (en POMs forælder). Det afhængighedLedelse elementssyntaks svarer til afsnittet om afhængighed. Hvad det gør, er dog at lade børn arve afhængighedsindstillinger, men ikke selve afhængigheden. Tilføjelse af en afhængighed med afhængighedLedelse element tilføjer faktisk ikke afhængigheden af POM, og det tilføjer heller ikke en afhængighed af børnene; det opretter en standardkonfiguration for enhver afhængighed, som et barn kan vælge at tilføje inden for sin egen afhængighedsafdeling. Indstillinger efter afhængighedLedelse gælder også for den aktuelle POM's afhængighedskonfiguration (selvom konfigurationer tilsidesat inde i afhængighedselementet altid har forrang).
Aggregering
Et projekt med moduler er kendt som et multimodulprojekt. Moduler er projekter, som en POM lister, udført som et sæt. Multimoduleprojekter kender deres moduler, men det omvendte er ikke nødvendigvis sandt, som det er vist i figur 6.
Antages det, at den overordnede POM er bosat i den overordnede mappe, hvor POM til projektet er -en lever, og at projektet -en også ligger i en mappe med samme navn, kan vi ændre den overordnede POM b at samle barnet -en ved at tilføje det som et modul:
4.0.0org.codehaus.mojob2pom-enNu hvis vi løb mvn kompilere i basekataloget, ville du se build starte med:
[INFO] Scanning efter projekter ... [INFO] Reaktoropbygningsrækkefølge: [INFO] Navnlig - org.codehaus.mojo: b: pom: 2 [INFO] Navnlig - org.codehaus.mojo: a: jar: 2 Maven-livscyklussen vil nu udføre op til den livscyklusfase, der er angivet i korrekt rækkefølge; det vil sige, at hver artefakt er bygget en ad gangen, og hvis en artefakt kræver, at en anden skal bygges først, vil den være.
En note om arv vs. aggregering
Arv og aggregering skaber en dejlig dynamik til styring af builds gennem en enkelt POM på højt niveau. Du vil ofte se projekter, der både er forældre og multimoduler, som eksemplet ovenfor. Deres komplementaritet gør dem til en naturlig match. Selv Maven 2-projektkernen løber gennem en enlig forælder / multimodule POM org.apache.maven: maven, så opbygning af et Maven 2-projekt kan udføres med en enkelt kommando: mvn kompilere. Selvom det bruges sammen, er en multimodul og en forælder ikke den samme og bør ikke forveksles. Et POM-projekt (der fungerer som forælder) kan arves fra, men det overordnede projekt samler ikke nødvendigvis nogen moduler. Omvendt kan et POM-projekt samle projekter, der ikke arver fra det.
Når alle fire stykker af ligningen er sat sammen, forhåbentlig vil du se kraften i Maven 2-forholdsmekanismen, som vist i figur 7.
Maven giver os en god ramme til at relatere projekter til hinanden, og gennem disse relationer kan vi skabe plug-ins, der kan genbruges af ethvert projekt, der følger Mavens konventioner. Men evnen til at styre projektforhold er kun en del af den overordnede Maven-ligning. Resten af POM beskæftiger sig ikke med andre projekter, men med dens build-indstillinger, dens information og dets miljø. Med en hurtig forståelse af, hvordan projekter relaterer sig til hinanden ud af vejen, lad os begynde at se på, hvordan en POM indeholder oplysninger om det rigtige projekt.
