Maven er et populært verktøy for åpen kildekode for Java-prosjekter, designet for å ta mye av det harde arbeidet ut av byggeprosessen. Maven bruker en deklarativ tilnærming, der prosjektstrukturen og innholdet er beskrevet, snarere enn den oppgavebaserte tilnærmingen som brukes i Ant eller i tradisjonelle make-filer, for eksempel. Dette hjelper med å håndheve utviklingsstandarder for hele selskapet og reduserer tiden det tar å skrive og vedlikeholde byggeskripter.
Den deklarative, livssyklusbaserte tilnærmingen som brukes av Maven 1 er for mange en radikal avvik fra mer tradisjonelle byggeteknikker, og Maven 2 går enda lenger i denne forbindelse. I denne artikkelen går jeg gjennom noen av de grunnleggende prinsippene bak Maven 2 og går deretter gjennom et arbeidseksempel. La oss starte med å gjennomgå grunnleggende om Maven 2.
Prosjektobjektmodellen
Hjertet i et Maven 2-prosjekt er prosjektobjektmodellen (eller kort sagt POM). Den inneholder en detaljert beskrivelse av prosjektet ditt, inkludert informasjon om versjons- og konfigurasjonsadministrasjon, avhengigheter, applikasjons- og testressurser, teammedlemmer og struktur og mye mer. POM har form av en XML-fil (pom.xml), som er plassert i prosjektets hjemmekatalog. En enkel pom.xml-fil vises her:
4.0.0 com.javaworld.hotels HotelDatabase war 1.0-SNAPSHOT Maven Quick Start Archetype //maven.apache.org junit junit 3.8.1 test Maven 2 katalogstruktur
Mye av Mavens kraft kommer fra standardpraksisen den oppmuntrer. En utvikler som tidligere har jobbet med et Maven-prosjekt, vil umiddelbart bli kjent med strukturen og organiseringen av et nytt. Tiden trenger ikke kastes bort på nytt å oppfinne katalogstrukturer, konvensjoner og tilpassede Ant-build-skript for hvert prosjekt. Selv om du kan overstyre et bestemt katalogsted for dine egne spesifikke mål, bør du virkelig respektere standard Maven 2-katalogstruktur så mye som mulig, av flere grunner:
- Det gjør POM-filen din mindre og enklere
- Det gjør prosjektet lettere å forstå og gjør livet lettere for den stakkars fyren som må opprettholde prosjektet når du reiser
- Det gjør det lettere å integrere plugin-moduler
Standard Maven 2-katalogstruktur er illustrert i figur 1. I prosjektets hjemmekatalog går POM (pom.xml) og to underkataloger: src for all kildekode og mål for genererte gjenstander.
Src-katalogen har et antall underkataloger, som hver har et klart definert formål:
- src / main / java: Java-kildekoden din kommer hit (merkelig nok!)
- src / main / resources: Andre ressurser søknaden din trenger
- src / main / filtre: Ressursfiltre, i form av egenskapsfiler, som kan brukes til å definere variabler som bare er kjent under kjøretid
- src / main / config: Konfigurasjonsfiler
- src / main / webapp: Webapplikasjonskatalogen for et WAR-prosjekt
- src / test / java: Enhetstester
- src / test / ressurser: Ressurser som skal brukes til enhetstester, men vil ikke bli distribuert
- src / test / filtre: Ressursfiltre som skal brukes til enhetstester, men vil ikke distribueres
- src / nettsted: Filer som brukes til å generere Maven-prosjektets nettsted
Prosjektets livssyklus
Prosjektets livssyklus er sentralt i Maven 2. De fleste utviklere er kjent med forestillingen om byggefaser som kompilering, test og distribusjon. Maur har mål med navn som de. I Maven 1 kalles tilsvarende plugin-moduler direkte. For å kompilere Java-kildekode, for eksempel java plug-in brukes:
$ maven java: kompilereI Maven 2 er denne oppfatningen standardisert i et sett med kjente og veldefinerte livssyklusfaser (se figur 2). I stedet for å påkalle plugins, påkaller Maven 2-utvikleren en livssyklusfase: $ mvn kompilere.
Noen av de mer nyttige Maven 2 livssyklusfasene er følgende:
generere kilder: Genererer hvilken som helst ekstra kildekode som trengs for applikasjonen, som vanligvis oppnås ved hjelp av de aktuelle plugin-modulenekompilere: Kompilerer prosjektets kildekodetest-kompilere: Kompilerer prosjektenhetstestenetest: Kjører enhetstestene (bruker vanligvis JUnit) i src / test-katalogenpakke: Pakker den kompilerte koden i distribuerbart format (JAR, WAR, etc.)integrasjonstest: Behandler og distribuerer pakken om nødvendig i et miljø der integrasjonstester kan kjøresinstallere: Installerer pakken i det lokale depotet for bruk som en avhengighet i andre prosjekter på din lokale maskinutplassere: Gjort i et integrerings- eller utgivelsesmiljø, kopierer den endelige pakken til det eksterne depotet for deling med andre utviklere og prosjekter
Mange andre livssyklusfaser er tilgjengelige. Se Ressurser for mer informasjon.
Disse fasene illustrerer fordelene med anbefalt praksis oppmuntret av Maven 2: Når en utvikler er kjent med de viktigste Maven 2 livssyklusfasene, bør han føle seg komfortabel med livssyklusfasene i ethvert Maven-prosjekt.
Livssyklusfasen påkaller plugin-modulene den trenger for å gjøre jobben. Å påkalle en livssyklusfase påkaller automatisk også eventuelle tidligere livssyklusfaser. Siden livssyklusfasene er begrenset i antall, enkle å forstå og godt organisert, er det enkelt å bli kjent med livssyklusen til et nytt Maven 2-prosjekt.
Transitive avhengigheter
Et av høydepunktene i Maven 2 er transitiv avhengighetsstyring. Hvis du noen gang har brukt et verktøy som urpmi på en Linux-boks, vet du hva transitive avhengigheter er. Med Maven 1 må du erklære hver JAR som er nødvendig, direkte eller indirekte, av søknaden din. Kan du for eksempel liste opp JAR-ene som kreves av en dvalemodus-applikasjon? Med Maven 2 trenger du ikke. Du forteller bare Maven hvilke biblioteker du trenger, og Maven vil ta seg av bibliotekene som bibliotekene dine trenger (og så videre).
Anta at du vil bruke dvalemodus i prosjektet ditt. Du vil ganske enkelt legge til en ny avhengighet til avhengigheter seksjon i pom.xml, som følger:
dvalemodus dvalemodus 3.0.3 kompilere Og det er det! Du trenger ikke å jakte rundt for å vite hvilke andre JARer (og i hvilke versjoner) du trenger for å kjøre Hibernate 3.0.3; Maven vil gjøre det for deg!
XML-strukturen for avhengigheter i Maven 2 er lik den som brukes i Maven 1. Hovedforskjellen er omfang , som er forklart i det følgende avsnittet.
Avhengighetsomfang
I et ekte foretaksapplikasjon trenger du kanskje ikke å ta med alle avhengighetene i det distribuerte programmet. Noen JAR-er trengs bare for enhetstesting, mens andre vil bli levert av runtime av applikasjonsserveren. Ved hjelp av en teknikk som heter avhengighetsomfang, Maven 2 lar deg bare bruke visse JAR når du virkelig trenger dem, og ekskluderer dem fra klassestien når du ikke trenger det.
Maven tilbyr fire avhengighetsomfang:
kompilere: En kompilitetsavhengighet er tilgjengelig i alle faser. Dette er standardverdien.sørget for: Avhengig avhengighet brukes til å kompilere applikasjonen, men blir ikke distribuert. Du vil bruke dette omfanget når du forventer at JDK eller applikasjonsserveren skal levere JAR. Servlet-APIene er et godt eksempel.kjøretid: Avhengigheter for kjøringstid er ikke nødvendig for kompilering, bare for kjøring, for eksempel JDBC (Java Database Connectivity) -drivere.test: Avhengighet av testomfang er bare nødvendig for å kompilere og kjøre tester (for eksempel JUnit).
Prosjektkommunikasjon
En viktig del av ethvert prosjekt er intern kommunikasjon. Selv om det ikke er en sølvkule, kan et sentralisert teknisk prosjekt Nettsted gå langt for å forbedre synligheten i teamet. Med minimal innsats kan du ha et profesjonelt kvalitetsprosjekt Nettsted i gang på veldig kort tid.
Dette tar en helt ny dimensjon når generasjonen av Maven-nettstedet integreres i en byggeprosess ved hjelp av kontinuerlig integrering eller til og med automatiske nattlige bygg. Et typisk Maven-nettsted kan publisere på daglig basis:
- Generell prosjektinformasjon som kildedepot, sporing av mangler, teammedlemmer osv.
- Enhetstest og testdekningsrapporter
- Automatiske kodevurderinger og med Checkstyle og PMD
- Konfigurasjons- og versjonsinformasjon
- Avhengigheter
- Javadoc
- Kildekode i indeksert og krysshenvist HTML-format
- Teammedlemsliste
- Og mye mer
Nok en gang vil enhver Maven-kunnskapsrik utvikler umiddelbart vite hvor de skal se for å bli kjent med et nytt Maven 2-prosjekt.
Et praktisk eksempel
Nå som vi har sett noen av de grunnleggende forestillingene som brukes i Maven 2, la oss se hvordan det fungerer i den virkelige verden. Resten av denne opplæringen undersøker hvordan vi vil bruke Maven 2 på et enkelt Java Enterprise Edition-prosjekt. Demosøknaden innebærer et imaginært (og forenklet) hotelldatabasesystem. For å demonstrere hvordan Maven håndterer avhengigheter mellom prosjekter og komponenter, blir denne applikasjonen bygget med to komponenter (se figur 3):
- En forretningslogikkomponent: HotelDatabase.jar
- En webapplikasjonskomponent: HotelWebApp.war
Du kan laste ned kildekoden for å følge opp veiledningen i Resources.
Sett opp prosjektmiljøet ditt
Vi starter med å konfigurere arbeidsmiljøet ditt. I virkelige prosjekter må du ofte definere og konfigurere miljø- eller brukerspesifikke parametere som ikke skal distribueres til alle brukere. Hvis du for eksempel står bak en brannmur med en proxy, må du konfigurere proxy-innstillingene slik at Maven kan laste ned JAR fra arkiver på nettet. For Maven 1-brukere gjør build.properties- og project.properties-filene denne jobben. I Maven 2 har de blitt erstattet av en settings.xml-fil, som går i $ HOME / .m2-katalogen. Her er et eksempel:
http scott tiger 8080 my.proxy.url Opprett et nytt prosjekt med arketypeprogrammet
Neste trinn er å lage en ny Maven 2-prosjektmal for virksomhetslogikkomponenten. Maven 2 gir arketype plug-in, som bygger en tom Maven 2-kompatibel prosjektkatalogstruktur. Denne plug-in viser seg praktisk for å få et grunnleggende prosjektmiljø i gang raskt. Standard arketypemodell vil produsere et JAR-biblioteksprosjekt. Flere andre gjenstandstyper er tilgjengelige for andre spesifikke prosjekttyper, inkludert webapplikasjoner, Maven-plugin-moduler og andre.
Kjør følgende kommando for å konfigurere HotelDatabase.jar-prosjektet:
mvn arketype: create -DgroupId = com.javaworld.hotels - DartifactId = HotelDatabase -Dpackagename = com.javaworld.hotelsNå har du en helt ny Maven 2-prosjektkatalogstruktur. Bytt til HotelDatabase katalog for å fortsette opplæringen.
Implementering av forretningslogikken
Nå implementerer vi forretningslogikken. De Hotell klasse er en enkel JavaBean. De HotelModel klasse implementerer to tjenester: findAvailableCities () metoden, som viser tilgjengelige byer, og findHotelsByCity () metode, som viser alle hotellene i en gitt by. En enkel, minnebasert implementering av HotelModel klasse presenteres her:
pakke com.javaworld.hotels.model;
importere java.util.ArrayList; importere java.util.List;
import com.javaworld.hotels.businessobjects.Hotel;
offentlig klasse HotelModel {
/ ** * Listen over alle kjente byer i databasen. * / private static String [] cities = {"Paris", "London",}; / ** * Listen over alle hotellene i databasen. * / private static Hotel [] hotels = {new Hotel ("Hotel Latin", "Quartier latin", "Paris", 3), new Hotel ("Hotel Etoile", "Place de l'Etoile", "Paris", 4), nytt hotell ("Hotel Vendome", "Place Vendome", "Paris", 5), nytt hotell ("Hotel Hilton", "Trafalgar Square", "London", 4), nytt hotell ("Hotel Ibis" , "The City", "London", 3),}; / ** * Returnerer hotellene i en gitt by. * @param by navnet på byen * @returner en liste over hotellobjekter * / offentlig Liste findHotelsByCity (String city) {List hotelsFound = new ArrayList (); for (Hotel hotel: hotels) {if (hotel.getCity (). equalsIgnoreCase (city)) {hotelsFound.add (hotel); }} returner hotellerFunnet; } / ** * Returnerer listen over byer i databasen som har et hotell. * @returner en liste over bynavn * / public String [] findAvailableCities () {returbyer; }}
