Apache Maven - Apache Maven

Apache Maven
Apache Maven logo.svg
Utvikler (er) Apache Software Foundation
Første utgivelse 13. juli 2004 ; 17 år siden ( 2004-07-13 )
Stabil utgivelse
3.8.3 / 27. september 2021 ; 14 dager siden ( 2021-09-27 )
Oppbevaringssted Maven -depot
Skrevet inn Java
Type Bygg verktøy
Tillatelse Apache lisens 2.0
Nettsted maven .apache .org

Maven er et byggautomatiseringsverktøy som hovedsakelig brukes til Java -prosjekter. Maven kan også brukes til å bygge og administrere prosjekter skrevet på C# , Ruby , Scala og andre språk. Maven -prosjektet er vert for Apache Software Foundation , der det tidligere var en del av Jakarta -prosjektet .

Maven tar for seg to aspekter ved å bygge programvare: hvordan programvare er bygget , og dets avhengigheter. I motsetning til tidligere verktøy som Apache Ant , bruker den konvensjoner for byggeprosedyren. Bare unntak må spesifiseres. En XML- fil beskriver programvareprosjektet som bygges, dets avhengighet av andre eksterne moduler og komponenter, byggeordren, kataloger og nødvendige plug-ins . Den kommer med forhåndsdefinerte mål for å utføre visse veldefinerte oppgaver, for eksempel samling av kode og emballasje. Maven laster dynamisk ned Java- biblioteker og Maven-plug-ins fra ett eller flere depoter, for eksempel Maven 2 Central Repository, og lagrer dem i en lokal hurtigbuffer. Denne lokale hurtigbufferen for nedlastede artefakter kan også oppdateres med artefakter som er opprettet av lokale prosjekter. Offentlige arkiver kan også oppdateres.

Maven er bygget ved hjelp av en plugin-basert arkitektur som lar den bruke alle programmer som kan kontrolleres gjennom standardinngang. En C / C ++ native plugin opprettholdes for Maven 2.

Alternative teknologier som Gradle og sbt som byggeverktøy er ikke avhengige av XML , men beholder nøkkelbegrepene Maven introdusert. Med Apache Ivy ble det også utviklet en dedikert avhengighetsleder som også støtter Maven -depoter.

Apache Maven har støtte for reproduserbare bygg .

Historie

Antall gjenstander på Mavens sentrale depot har vokst raskt

Maven, skapt av Jason van Zyl, begynte som et delprosjekt av Apache Turbine i 2002. I 2003 ble det stemt over og akseptert som et prosjekt på toppnivå Apache Software Foundation . I juli 2004 var Mavens utgivelse den kritiske første milepælen, v1.0. Maven 2 ble deklarert v2.0 i oktober 2005 etter omtrent seks måneder i betasykluser. Maven 3.0 ble utgitt i oktober 2010 og var for det meste bakoverkompatibel med Maven 2.

Maven 3.0-informasjon begynte å sive ut i 2008. Etter åtte alfa-utgivelser ble den første betaversjonen av Maven 3.0 utgitt i april 2010. Maven 3.0 har omarbeidet kjernen i Project Builder-infrastrukturen, noe som resulterte i at POMs filbaserte representasjon ble koblet fra sin in- minneobjektrepresentasjon. Dette har utvidet muligheten for Maven 3.0-tillegg til å utnytte ikke-XML-baserte prosjektdefinisjonsfiler. Språk som foreslås inkluderer Ruby (allerede i privat prototype av Jason van Zyl), YAML og Groovy .

Spesiell oppmerksomhet ble gitt for å sikre bakoverkompatibilitet mellom Maven 3 og Maven 2. For de fleste prosjekter vil oppgradering til Maven 3 ikke kreve noen justeringer av prosjektstrukturen. I den første betaen av Maven 3 ble det introdusert en parallell byggefunksjon som utnytter et konfigurerbart antall kjerner på en flerkjernemaskin og er spesielt egnet for store flermodulsprosjekter.

Syntaks

En katalogstruktur for et Java-prosjekt som er automatisk generert av Maven

Maven -prosjekter konfigureres ved hjelp av en Project Object Model (POM) , som er lagret i en pom.xml-fil. En eksempelfil ser slik ut: 

<project>
  <!-- model version is always 4.0.0 for Maven 2.x POMs -->
  <modelVersion>4.0.0</modelVersion>
  <!-- project coordinates, i.e. a group of values which uniquely identify this project -->
  <groupId>com.mycompany.app</groupId>
  <artifactId>my-app</artifactId>
  <version>1.0</version>
  <!-- library dependencies -->
  <dependencies>
    <dependency>
      <!-- coordinates of the required library -->
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8.1</version>
      <!-- this dependency is only used for running and compiling tests -->
      <scope>test</scope>
    </dependency>
  </dependencies>
</project>

Denne POM definerer bare en unik identifikator for prosjektet ( koordinater ) og dets avhengighet av JUnit -rammeverket . Imidlertid er det allerede nok for å bygge prosjektet og kjøre enhetstester knyttet til prosjektet. Maven oppnår dette ved å omfavne ideen om konvensjon over konfigurasjon , det vil si at Maven gir standardverdier for prosjektets konfigurasjon.

Katalogstrukturen til et normalt idiomatisk Maven -prosjekt har følgende katalogoppføringer:

Katalognavn Hensikt
prosjekt hjem Inneholder pom.xml og alle underkataloger.
src/main/java Inneholder den leverbare Java -kildekoden for prosjektet.
src/main/resources Inneholder leverbare ressurser for prosjektet, for eksempel eiendomsfiler.
src/test/java Inneholder test -Java -kildekoden (for eksempel JUnit- eller TestNG -testtilfeller) for prosjektet.
src/test/ressurser Inneholder nødvendige ressurser for testing.

Kommandoen mvn packagevil kompilere alle Java-filene, kjøre eventuelle tester og pakke den leverbare koden og ressursene inn i target/my-app-1.0.jar(forutsatt at artifactId er min app og versjonen er 1.0.)

Ved bruk av Maven gir brukeren bare konfigurasjon for prosjektet, mens de konfigurerbare plugin-modulene gjør selve arbeidet med å kompilere prosjektet, rense målkataloger, kjøre enhetstester, generere API-dokumentasjon og så videre. Generelt skal brukerne ikke måtte skrive plugins selv. Kontrast dette med Ant and make , der man skriver tvingende prosedyrer for å utføre de nevnte oppgavene.

Design

Prosjektobjektmodell

En Project Object Model (POM) gir all konfigurasjon for et enkelt prosjekt. Generell konfigurasjon dekker prosjektets navn, eier og avhengighet av andre prosjekter. Man kan også konfigurere individuelle faser av byggeprosessen, som implementeres som plugins . For eksempel kan man konfigurere kompilator-plugin til å bruke Java versjon 1.5 for kompilering, eller angi pakking av prosjektet selv om noen enhetstester mislykkes.

Større prosjekter bør deles inn i flere moduler, eller delprosjekter, hver med sin egen POM. Man kan deretter skrive en rot -POM som man kan kompilere alle modulene med en enkelt kommando. POM -er kan også arve konfigurasjon fra andre POM -er. Alle POMs arver fra Super POM som standard. Super POM gir standardkonfigurasjon, for eksempel standard kildekataloger, standard plugins og så videre.

Plug-ins

Det meste av Mavens funksjonalitet er plug-ins . En plugin gir et sett med mål som kan utføres ved hjelp av kommandoen mvn [plugin-name]:[goal-name]. For eksempel kan et Java-prosjekt kompileres med kompiler-plugins kompileringsmål ved å kjøre mvn compiler:compile.

Det er Maven -plugins for bygging, testing, styring av kildekontroll, drift av en webserver, generering av Eclipse -prosjektfiler og mye mer. Plugins blir introdusert og konfigurert i en <plugins> -del av en pom.xmlfil. Noen grunnleggende plugins er inkludert i hvert prosjekt som standard, og de har fornuftige standardinnstillinger.

Imidlertid vil det være tungvint hvis den arketypiske byggesekvensen for å bygge, teste og pakke et programvareprosjekt krever at hvert respektive mål kjøres manuelt:

  • mvn compiler:compile
  • mvn surefire:test
  • mvn jar:jar

Mavens livssykluskonsept håndterer dette problemet.

Plugins er den viktigste måten å utvide Maven. Å utvikle en Maven -plugin kan gjøres ved å utvide klassen org.apache.maven.plugin.AbstractMojo. Eksempelkode og forklaring på en Maven-plugin for å lage en skybasert virtuell maskin som kjører en applikasjonsserver, er gitt i artikkelen Automatiser utvikling og administrasjon av virtuelle nettskymaskiner .

Bygg livssykluser

Byggets livssyklus er en liste over navngitte faser som kan brukes til å gi orden i målgjennomføringen. En av Mavens standard livssykluser er standard livssyklus , som inkluderer følgende faser, i denne rekkefølgen:

  • validere
  • generere-kilder
  • prosesskilder
  • generere ressurser
  • prosessressurser
  • kompilere
  • prosess-test-kilder
  • prosess-test-ressurser
  • test-kompilere
  • test
  • pakke
  • installere
  • utplassere

Mål levert av plugins kan være assosiert med forskjellige faser av livssyklusen. For eksempel er målet "kompilator: kompilering" som standard knyttet til "kompiler" -fasen, mens målet "surefire: test" er knyttet til "test" -fasen. Når mvn testkommandoen er utført, kjører Maven alle målene knyttet til hver av fasene til og med "test" -fasen. I et slikt tilfelle kjører Maven målet "ressurser: ressurser" knyttet til "prosessressurser" -fasen, deretter "kompilator: kompiler", og så videre til det til slutt kjører målet "surefire: test".

Maven har også standardfaser for rengjøring av prosjektet og for å generere et prosjektsted. Hvis rengjøring var en del av standard livssyklus, ville prosjektet bli rengjort hver gang det ble bygget. Dette er helt klart uønsket, så rengjøring har fått sin egen livssyklus.

Standard livssykluser gir brukere som er nye i et prosjekt muligheten til å bygge, teste og installere hvert Maven -prosjekt nøyaktig ved å utstede den ene kommandoen mvn install. Som standard pakker Maven POM -filen i genererte JAR- og WAR -filer. Verktøy som diet4j kan bruke denne informasjonen til å rekursivt løse og kjøre Maven-moduler ved kjøretid uten å kreve en "uber" -jar som inneholder all prosjektkode.

Avhengigheter

Et sentralt trekk i Maven er avhengighetsbehandling . Mavens mekanisme for avhengighetsbehandling er organisert rundt et koordinatsystem som identifiserer individuelle artefakter som programvarebiblioteker eller moduler. POM -eksemplet ovenfor refererer til JUnit -koordinatene som en direkte avhengighet av prosjektet. Et prosjekt som trenger, for eksempel, Hibernate -biblioteket, må bare deklarere Hibernates prosjektkoordinater i POM. Maven vil automatisk laste ned avhengigheten og avhengighetene som Hibernate selv trenger (kalt transitive avhengigheter ) og lagre dem i brukerens lokale depot. Maven 2 Central Repository brukes som standard for å søke etter biblioteker, men man kan konfigurere depotene som skal brukes (f.eks. Bedriftsprivatte depoter) i POM.

Den grunnleggende forskjellen mellom Maven og Ant er at Mavens design anser at alle prosjekter har en viss struktur og et sett med støttede arbeidsflyter (f.eks. Å få ressurser fra kildekontroll, kompilere prosjektet, enhetstesting, etc.). Selv om de fleste programvareprosjekter faktisk støtter disse operasjonene og faktisk har en veldefinert struktur, krever Maven at denne strukturen og detaljene for driftsimplementering defineres i POM-filen. Dermed er Maven avhengig av en konvensjon om hvordan man definerer prosjekter og på listen over arbeidsflyter som vanligvis støttes i alle prosjekter.

Det er søkemotorer som The Central Repository Search Engine, som kan brukes til å finne ut koordinater for forskjellige bibliotek og rammeverk med åpen kildekode.

Prosjekter utviklet på en enkelt maskin kan avhenge av hverandre gjennom det lokale depotet. Det lokale depotet er en enkel mappestruktur som fungerer både som en hurtigbuffer for nedlastede avhengigheter og som et sentralisert lagringssted for lokalt bygde artefakter. Maven -kommandoen mvn installbygger et prosjekt og plasserer binære filer i det lokale depotet. Deretter kan andre prosjekter bruke dette prosjektet ved å spesifisere koordinatene i POM -ene.

Interoperabilitet

Tillegg til flere populære integrerte utviklingsmiljøer (IDE) som er rettet mot Java-programmeringsspråket finnes for å gi integrasjon av Maven med IDEs byggemekanisme og kilderedigeringsverktøy, slik at Maven kan kompilere prosjekter innenfra IDE, og også sette klassen til fullføring av kode, utheving av kompilatorfeil, etc.

Eksempler på populære IDEer som støtter utvikling med Maven inkluderer:

Disse tilleggene gir også muligheten til å redigere POM eller bruke POM til å bestemme et projekts komplette sett med avhengigheter direkte i IDE.

Noen innebygde funksjoner i IDE taps når IDE ikke lenger utfører kompilering. For eksempel har Eclipses JDT muligheten til å kompilere en enkelt Java -kildefil etter at den har blitt redigert. Mange IDE -er jobber med et flatt sett med prosjekter i stedet for hierarkiet av mapper som Maven foretrekker. Dette kompliserer bruken av SCM -systemer i IDE -er ved bruk av Maven.

Se også

Referanser

Videre lesning

Eksterne linker