Å bygge et prosjekt er en kompleks virksomhet. På grunn av de mange oppgavene som kreves for å konvertere din hodge-podge av filer til et fungerende program, finnes det bokstavelig talt hundrevis av verktøy som gjør alt fra å generere kildekode, til kompilering, til testing, til distribusjon, til å brygge morgenkaffen (hvis du finner en, kjære leser, gi meg beskjed). Mange av disse programmene er gode til det de gjør. Dessverre er det sjelden mye fellestrekk for de av oss som administrerer store byggesystemer for å leve. hvert program krever sin egen forskjellige installasjon og esoteriske konfigurasjon. Det har blitt et uunngåelig faktum i våre liv at flertallet av byggesystemene er spesialbygd ved håndliming av disse verktøyene med flere hjemmebryggeskripter (ja, Ant-skript teller).
Mer enn et annet byggeverktøy, Maven er et bygg rammeverk. Den skiller koden din rent fra konfigurasjonsfiler, dokumentasjon og avhengigheter. Maven er overraskende fleksibel når det gjelder å la brukerne konfigurere de fleste aspekter av koden, så vel som å kontrollere oppførselen til plugin-moduler, individuelle mål og til og med selve byggesyklusen. Maven er selve strukturen, og innenfor disse veggene bor prosjektet ditt; det ønsker å være en imøtekommende vert.
Men problemet er fortsatt: å administrere arbeidet til tusenvis av tilpassede byggeskripter innen ett rammeverk er vanskelig og for å bli gjort riktig krever mye informasjon. Heldigvis har Maven 2-teamet vært ganske vellykket. Lær av feilene til Maven 1, utallige brukerforespørsler, tilpasning og oppdatering, er Maven 2 kraftigere enn noen gang. Dessverre, med stor kraft kommer flott konfigurasjon. For at Maven 2-gjenstander skal være lett bærbare enheter, faller den komplekse konfigurasjonen i en enkelt fil. Gå inn i Maven POM.
Hva er POM?
POM står for prosjektobjektmodell. Det er en XML-representasjon av et Maven-prosjekt som holdes i en fil som heter pom.xml. I nærvær av Maven-folk snakker det om et prosjekt i filosofisk forstand, utover bare en samling filer som inneholder kode. Et prosjekt inneholder konfigurasjonsfiler, så vel som involverte utviklere og roller de spiller, feilsporingssystemet, organisasjonen og lisensene, URL-en der prosjektet bor, prosjektets avhengighet og alle de andre små brikkene som spiller inn for å gi kode liv. Et prosjekt er en one-stop shop for alle ting knyttet til det. Faktisk, i Maven-verdenen, trenger et prosjekt ikke å inneholde noen kode i det hele tatt, bare en pom.xml. Vi vil møte et par slike typer prosjekter senere i artikkelen.
En rask strukturell oversikt
POM er stor og kompleks, så å bryte den i stykker letter fordøyelsen. I forbindelse med denne diskusjonen er disse delene omgruppert i fire logiske enheter, som vist i figur 1: POM-forhold, prosjektinformasjon, byggeinnstillinger og byggemiljø. Vi skal begynne med å diskutere POM-forhold.
Nedenfor er en liste over elementene direkte under POMs prosjektelement. Legg merke til det modellversjon inneholder 4.0.0. Det er for øyeblikket den eneste støttede POM-versjonen for Maven 2, og er alltid nødvendig. Maven 4.0.0 XML-skjemadefinisjonen ligger på //maven.apache.org/maven-v4_0_0.xsd. Elementene på toppnivå er som følger:
4.0.0
... ... ... ... ... ... ...
... ... ... ... ... ... ... ...
... ... ... ...
... ... ... ...
... ... ... ... ...
POM-forhold
Vår første forretningsordre er å undersøke prosjektforhold, representert i figur 2 som det øverste venstre hjørnet av diagrammet i figur 1.
Prosjekter må på noen måte forholde seg til hverandre. Siden etableringen av de første montørene har programvareprosjekter hatt avhengigheter; Maven har introdusert flere former for forhold hittil ubrukt i en slik form for Java-prosjekter. Disse forholdene er Maven-koordinater, koordinatbaserte avhengigheter, prosjektarv og aggregering.
Koordinater
Hvert Maven-prosjekt inneholder sin egen unike identifikator, kalt prosjektets koordinater, som fungerer som en gjenstands adresse, og gir den et unikt sted i Maven-universet. Hvis prosjekter ikke hadde noen måte å forholde seg til hverandre, ville det ikke være behov for koordinater. Det vil si at hvis et univers bare hadde ett hus, hvorfor skulle det trenge en adresse som Cherrywood Lane 315?
Koden nedenfor er minimum POM som Maven 2 tillater -, , og er alle obligatoriske felt. De fungerer som en vektor i Maven-rommet med elementene grouper, identifikator og tidsstempel.
4.0.0org.codehaus.mojoen1I Maven-verdenen utgjør disse tre hovedelementene (The Maven-treenigheten - se dens herlighet!) En POM-koordinater. Koordinatene er representert av figur 3.
Kanskje denne POM ikke er så imponerende av seg selv. Det blir bedre.
Avhengigheter
En av de kraftigste aspektene ved Maven er håndteringen av prosjektavhengigheter, og i Maven 2, som inkluderer transitive avhengigheter. Figur 4 illustrerer hvordan vi skal representere dem grafisk.
Avhengighetsstyring har en lang tradisjon for å være et komplisert rot for alt annet enn det mest trivielle av prosjekter. "Jarmageddon" følger raskt etter hvert som avhengighetstreet blir stort, komplisert og pinlig for arkitekter som blir hånet av nyutdannede som "helt kunne gjort det bedre." "Jar Hell" følger, der versjoner av avhengigheter på ett system ikke er helt de samme versjonene som de som ble brukt for utvikling; de har enten feil versjon eller motstridende versjoner mellom JAR-er som har samme navn. Derfor begynner ting å brytes og finne ut hvorfor det viser seg vanskelig. Maven løser begge disse problemene ved å ha et felles lokalt arkiv hvorfra man kan koble til riktige prosjekter, versjoner og alt.
Arv
En av funksjonene som Maven 2 bringer fra Maven 1 dager er prosjektarv, som vist i figur 5. I byggesystemer, som Ant, kan arv absolutt simuleres, men Maven har tatt det ekstra trinnet for å gjøre prosjektarv eksplisitt for prosjektobjektmodellen.
Følgende kode definerer en overordnet POM i Maven 2:
4.0.0org.codehaus.mojob2pomDenne forelderen ligner på vår første POM, med en liten forskjell. Legg merke til at vi har satt inn emballasje skriv inn som pom, som kreves for både foreldre- og samleprosjekter (vi vil dekke mer om emballasje i delen "Byggeinnstillinger"). Hvis vi ønsker å bruke ovennevnte prosjekt som foreldre, kan vi endre prosjektet org.codehaus.mojo: a POM å være:
4.0.0org.codehaus.mojob2enDet er viktig å merke seg at alle POM-er arver fra en foreldre, enten de er eksplisitt definert eller ikke. Denne grunnleggende POM er kjent som "super POM", og inneholder verdier som er arvet som standard. En enkel måte å se på standardkonfigurasjonene til super POM er ved å lage en enkel pom.xml uten annet enn modellversjon, groupId, artefaktId, og versjon, og kjører kommandoen mvn hjelp: effektiv-pom.
Utover å bare sette verdier som skal arves, har foreldre også makten til å lage standardkonfigurasjoner for barna sine uten å faktisk pålegge dem verdier. Avhengighetsadministrasjon er et spesielt kraftig instrument for å konfigurere et sett avhengigheter gjennom en felles plassering (en POMs foreldre). De avhengighetLedelse element-syntaksen ligner på avhengighetsdelen. Det den gjør, er imidlertid at barn kan arve avhengighetsinnstillinger, men ikke selve avhengigheten. Legge til en avhengighet med avhengighetLedelse elementet tilfører faktisk ikke avhengigheten til POM, og det legger heller ikke en avhengighet til barna; det oppretter en standardkonfigurasjon for avhengighet som et barn kan velge å legge til i sin egen avhengighetsseksjon. Innstillinger etter avhengighetLedelse gjelder også for gjeldende POMs avhengighetskonfigurasjon (selv om konfigurasjoner overstyrt i avhengighetselementet alltid har forrang).
Aggregasjon
Et prosjekt med moduler er kjent som et multimodulprosjekt. Moduler er prosjekter som en POM lister, utført som et sett. Multimodule-prosjekter kjenner til modulene sine, men det motsatte er ikke nødvendigvis sant, som vist i figur 6.
Forutsatt at foreldre-POM bor i foreldrekatalogen der POM for prosjektet er en lever, og at prosjektet en ligger også i en katalog med samme navn, kan vi endre den overordnede POM b å samle barnet en ved å legge den til som en modul:
4.0.0org.codehaus.mojob2pomenNå hvis vi løp mvn kompilere i basiskatalogen, vil du se build starte med:
[INFO] Skanner etter prosjekter ... [INFO] Reaktorens byggrekkefølge: [INFO] Navnlig - org.codehaus.mojo: b: pom: 2 [INFO] Navnlig - org.codehaus.mojo: a: jar: 2 Maven livssyklus vil nå kjøres opp til livssyklusfasen spesifisert i riktig rekkefølge; det vil si at hver gjenstand er bygget en om gangen, og hvis en gjenstand krever at en annen bygges først, vil den være.
Et notat om arv kontra aggregering
Arv og aggregering skaper en fin dynamikk for å kontrollere bygninger gjennom en enkelt POM på høyt nivå. Du vil ofte se prosjekter som er både foreldre og multimoduler, som eksemplet ovenfor. Deres komplementaritet gjør dem til en naturlig kamp. Selv Maven 2-prosjektkjernen går gjennom en enslig forelder / multimodule POM org.apache.maven: maven, så å bygge et Maven 2-prosjekt kan utføres med en enkelt kommando: mvn kompilere. Selv om det brukes sammen, er en multimodule og en forelder ikke den samme, og bør ikke forveksles. Et POM-prosjekt (som foreldre) kan arves fra, men det overordnede prosjektet samler ikke nødvendigvis noen moduler. Motsatt kan et POM-prosjekt samle prosjekter som ikke arver fra det.
Når alle fire delene av ligningen er satt sammen, vil du forhåpentligvis se kraften til Maven 2-forholdsmekanismen, som vist i figur 7.
Maven gir oss et fint rammeverk for å relatere prosjekter til hverandre, og gjennom disse forholdene kan vi lage plugin-moduler som kan gjenbrukes av ethvert prosjekt som følger Mavens konvensjoner. Men evnen til å håndtere prosjektrelasjoner er bare en del av den totale Maven-ligningen. Resten av POM er ikke opptatt av andre prosjekter, men med innstillinger for bygging, informasjon og miljø. Med en rask forståelse av hvordan prosjekter forholder seg til hverandre, kan vi begynne å se på hvordan en POM inneholder informasjon om prosjektet.
