Maven er et populært open source-byggeværktøj til Java-projekter til virksomheder, designet til at tage meget af det hårde arbejde ud af byggeprocessen. Maven bruger en deklarativ tilgang, hvor projektstrukturen og indholdet er beskrevet, snarere end den opgavebaserede tilgang, der bruges i Ant eller i traditionelle make-filer, for eksempel. Dette hjælper med at håndhæve virksomhedsdækkende udviklingsstandarder og reducerer den nødvendige tid til at skrive og vedligeholde build-scripts.
Den deklarative, livscyklusbaserede tilgang, der anvendes af Maven 1, er for mange en radikal afvigelse fra mere traditionelle byggeteknikker, og Maven 2 går endnu længere i denne henseende. I denne artikel gennemgår jeg nogle af de grundlæggende principper bag Maven 2 og går derefter gennem et arbejdseksempel. Lad os starte med at gennemgå fundamentet i Maven 2.
Projektobjektmodellen
Hjertet i et Maven 2-projekt er projektobjektmodellen (eller kort sagt POM). Den indeholder en detaljeret beskrivelse af dit projekt, herunder oplysninger om versionering og konfigurationsstyring, afhængigheder, applikations- og testressourcer, teammedlemmer og struktur og meget mere. POM har form af en XML-fil (pom.xml), som er placeret i dit projekts hjemmekatalog. En simpel 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-katalogstrukturen
Meget af Mavens magt kommer fra den standardpraksis, den tilskynder til. En udvikler, der tidligere har arbejdet på et Maven-projekt, vil straks kende strukturen og organisationen af en ny. Tiden behøver ikke spildes med at genopfinde katalogstrukturer, konventioner og tilpassede Ant-build-scripts til hvert projekt. Selvom du kan tilsidesætte en bestemt katalogplacering til dine egne specifikke ender, skal du virkelig respektere standard Maven 2-katalogstrukturen så meget som muligt af flere grunde:
- Det gør din POM-fil mindre og enklere
- Det gør projektet lettere at forstå og gør livet lettere for den stakkels fyr, der skal vedligeholde projektet, når du forlader
- Det gør det lettere at integrere plug-ins
Standard Maven 2-katalogstrukturen er illustreret i figur 1. I projektets hjemmekatalog vises POM (pom.xml) og to underkataloger: src for al kildekode og mål for genererede artefakter.
Src-biblioteket har et antal underkataloger, som hver har et klart defineret formål:
- src / main / java: Din Java-kildekode går her (underligt nok!)
- src / main / ressourcer: Andre ressourcer, din applikation har brug for
- src / main / filtre: Ressourcefiltre i form af egenskabsfiler, der kan bruges til at definere variabler, der kun er kendt under kørsel
- src / main / config: Konfigurationsfiler
- src / main / webapp: Webapplikationsmappen til et WAR-projekt
- src / test / java: Enhedstest
- src / test / ressourcer: Ressourcer, der skal bruges til enhedstest, men vil ikke blive brugt
- src / test / filtre: Ressourcefiltre, der skal bruges til enhedstest, men vil ikke blive implementeret
- src / site: Filer, der bruges til at generere Maven-projektets websted
Projektets livscyklus
Projektets livscyklusser er centrale for Maven 2. De fleste udviklere er fortrolige med forestillingen om byggefaser såsom kompilering, test og implementering. Ant har mål med navne som dem. I Maven 1 kaldes tilsvarende plug-ins direkte. For at kompilere Java-kildekode, f.eks java plug-in bruges:
$ maven java: kompilereI Maven 2 er denne opfattelse standardiseret i et sæt velkendte og veldefinerede livscyklusfaser (se figur 2). I stedet for at påkalde plug-ins påberåber Maven 2-udvikleren en livscyklusfase: $ mvn kompilering.
Nogle af de mere nyttige Maven 2-livscyklusfaser er følgende:
generere kilder: Genererer enhver ekstra kildekode, der er nødvendig til applikationen, hvilket normalt opnås ved hjælp af de relevante plug-insudarbejde: Kompilerer projektets kildekodetest-kompilere: Kompilerer testene til projektenhedenprøve: Kører enhedstestene (typisk ved hjælp af JUnit) i biblioteket src / testpakke: Pakker den kompilerede kode i distribuerbart format (JAR, WAR osv.)integration-test: Behandler og implementerer pakken om nødvendigt i et miljø, hvor integrationstests kan køresinstallere: Installerer pakken i det lokale lager til brug som en afhængighed i andre projekter på din lokale maskineindsætte: Udført i et integrations- eller frigivelsesmiljø, kopierer den endelige pakke til fjernlageret til deling med andre udviklere og projekter
Mange andre livscyklusfaser er tilgængelige. Se Ressourcer for flere detaljer.
Disse faser illustrerer fordelene ved den anbefalede praksis, der tilskyndes af Maven 2: når en udvikler er fortrolig med de vigtigste Maven 2-livscyklusfaser, skal han føle sig godt tilpas med livscyklusfaserne i ethvert Maven-projekt.
Livscyklusfasen påberåber de plug-ins, den har brug for til at udføre jobbet. Påkald af en livscyklusfase påberåber automatisk også eventuelle tidligere livscyklusfaser. Da livscyklusfaserne er begrænset i antal, let at forstå og velorganiseret, er det nemt at blive fortrolig med livscyklussen i et nyt Maven 2-projekt.
Transitive afhængigheder
Et af højdepunkterne i Maven 2 er transitiv afhængighedsstyring. Hvis du nogensinde har brugt et værktøj som urpmi på en Linux-boks, ved du hvad transitive afhængigheder er. Med Maven 1 skal du erklære hver eneste JAR, der er nødvendig, direkte eller indirekte, af din ansøgning. Kan du f.eks. Angive de JAR, der er nødvendige for en dvale-applikation? Med Maven 2 behøver du ikke. Du fortæller bare Maven hvilke biblioteker du behov, og Maven tager sig af de biblioteker, som dine biblioteker har brug for (og så videre).
Antag, at du vil bruge dvale i dit projekt. Du tilføjer simpelthen en ny afhængighed af afhængigheder sektion i pom.xml, som følger:
dvale dvale 3.0.3 kompilere Og det er det! Du behøver ikke at jage rundt for at vide, i hvilke andre JAR'er (og i hvilke versioner) du har brug for at køre Hibernate 3.0.3; Maven vil gøre det for dig!
XML-strukturen for afhængigheder i Maven 2 svarer til den, der anvendes i Maven 1. Den største forskel er rækkevidde tag, som forklares i det følgende afsnit.
Afhængighedsomfang
I en virkelighedens virksomhedsapplikation behøver du muligvis ikke at medtage alle afhængigheder i den implementerede applikation. Nogle JAR'er er kun nødvendige til enhedstest, mens andre leveres ved kørsel af applikationsserveren. Ved hjælp af en teknik kaldet afhængighedsomfang, Maven 2 lader dig kun bruge bestemte JAR'er, når du virkelig har brug for dem og udelukker dem fra klassestien, når du ikke har det.
Maven leverer fire afhængighedsomfang:
udarbejde: En afhængighed af kompilering er tilgængelig i alle faser. Dette er standardværdien.stillet til rådighed: En forudsat afhængighed bruges til at kompilere applikationen, men vil ikke blive implementeret. Du bruger dette omfang, når du forventer, at JDK eller applikationsserveren leverer JAR. Servlet-API'erne er et godt eksempel.runtime: Afhængigheder af kørselstid er ikke nødvendige til kompilering, kun til udførelse, såsom JDBC (Java Database Connectivity) -drivere.prøve: Test-omfangsafhængigheder er kun nødvendige for at kompilere og køre tests (f.eks. JUnit).
Projektkommunikation
En vigtig del af ethvert projekt er intern kommunikation. Selvom det ikke er en sølvkugle, kan et centralt teknisk projektwebsted gå langt i retning af at forbedre synligheden i teamet. Med minimal indsats kan du have et websted med professionel kvalitet, der kører på meget kort tid.
Dette tager en helt ny dimension, når Maven-webstedsgenerationen integreres i en byggeproces ved hjælp af kontinuerlig integration eller endda automatiske natlige bygninger. Et typisk Maven-websted kan offentliggøre dagligt:
- Generelle projektoplysninger såsom kildeopbevaringssteder, mangelfølgning, teammedlemmer osv.
- Enhedstest og testdækningsrapporter
- Automatiske kodevurderinger og med Checkstyle og PMD
- Oplysninger om konfiguration og versionering
- Afhængigheder
- Javadoc
- Kildekode i indekseret og krydsrefereret HTML-format
- Teammedlemsliste
- Og meget mere
Endnu en gang vil enhver Maven-kyndig udvikler straks vide, hvor de skal se for at blive fortrolige med et nyt Maven 2-projekt.
Et praktisk eksempel
Nu hvor vi har set et par af de grundlæggende forestillinger brugt i Maven 2, lad os se, hvordan det fungerer i den virkelige verden. Resten af denne vejledning undersøger, hvordan vi ville bruge Maven 2 på et simpelt Java Enterprise Edition-projekt. Demoprogrammet involverer et imaginært (og forenklet) hoteldatabasesystem. For at demonstrere, hvordan Maven håndterer afhængigheder mellem projekter og komponenter, bygges denne applikation ved hjælp af to komponenter (se figur 3):
- En forretningslogisk komponent: HotelDatabase.jar
- En webapplikationskomponent: HotelWebApp.war
Du kan downloade kildekoden for at følge med i vejledningen i Ressourcer.
Opret dit projektmiljø
Vi starter med at konfigurere dit arbejdsmiljø. I virkelige projekter bliver du ofte nødt til at definere og konfigurere miljø- eller brugerspecifikke parametre, der ikke skal distribueres til alle brugere. Hvis du f.eks. Står bag en firewall med en proxy, skal du konfigurere proxyindstillingerne, så Maven kan downloade JAR'er fra arkiver på Internettet. For brugere af Maven 1 gør build.properties- og project.properties-filerne dette job. I Maven 2 er de blevet erstattet af en settings.xml-fil, der findes i $ HOME / .m2-biblioteket. Her er et eksempel:
http scott tiger 8080 my.proxy.url Opret et nyt projekt med arketype-plug-in
Det næste trin er at oprette en ny Maven 2-projektskabelon til forretningslogikomponenten. Maven 2 leverer arketype plug-in, som bygger en tom Maven 2-kompatibel projektmappestruktur. Denne plug-in viser sig praktisk at få et grundlæggende projektmiljø til at køre hurtigt. Standardarketypemodellen producerer et JAR-biblioteksprojekt. Flere andre artefakttyper er tilgængelige for andre specifikke projekttyper, herunder webapplikationer, Maven-plugins og andre.
Kør følgende kommando for at opsætte dit HotelDatabase.jar-projekt:
mvn arketype: Opret -DgroupId = com.javaworld.hotels - DartifactId = HotelDatabase -Dpackagename = com.javaworld.hotelsNu har du en splinterny Maven 2-projektmappestruktur. Skift til HotelDatabase bibliotek for at fortsætte vejledningen.
Implementering af forretningslogikken
Nu implementerer vi forretningslogikken. Det Hotel klasse er en simpel JavaBean. Det HotelModel klasse implementerer to tjenester: findAvailableCities () metode, der viser tilgængelige byer og findHotelsByCity () metode, der viser alle hoteller i en given by. En simpel, hukommelsesbaseret implementering af HotelModel klasse præsenteres 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 kendte byer i databasen. * / privat statisk streng [] byer = {"Paris", "London",}; / ** * Listen over alle hoteller i databasen. * / privat statisk hotel [] hoteller = {nyt hotel ("Hotel Latin", "Quartier latin", "Paris", 3), nyt hotel ("Hotel Etoile", "Place de l'Etoile", "Paris", 4), nyt hotel ("Hotel Vendome", "Place Vendome", "Paris", 5), nyt hotel ("Hotel Hilton", "Trafalgar Square", "London", 4), nyt hotel ("Hotel Ibis" , "The City", "London", 3),}; / ** * Returnerer hotellerne i en given by. * @param by navnet på byen * @ returner en liste med hotelobjekter * / offentlig Liste findHotelsByCity (String city) {List hotelsFound = new ArrayList (); for (Hotel hotel: hotels) {if (hotel.getCity (). equalsIgnoreCase (city)) {hotelsFound.add (hotel); }} returner hotellerFundet; } / ** * Returnerer listen over byer i databasen, der har et hotel. * @ returner en liste med bynavne * / public String [] findAvailableCities () {returbyer; }}
