I takt med att mjukvaran blivit mer komplex har behovet av standardiserade och dynamiska byggssystem blivit allt större. Min ringa erfarenhet av byggare sträcker sig till Make, Ant och nu senast Maven.
Make var svårt att undvika när man väl kom in i Unixvärlden, som ofta är synonymt med universitetsvärlden. Genom åren har man hört ett och annat okvädningsord om Make, men personligen förstår jag inte riktigt varför, speciellt inte efter ha mött Ant.
Det stora problemet med Ant är att man har tagit ett sk. uppmärkningsspråk (mark-up language) som i bästa fall kan klassas som deklarativt och sedan försökt införa kontrollflöde ovan på det. Dessutom får jag en känsla av att hela språket genomsyras av bristande kunskap om hur man designar språk, ett problem som i sig räknas som ett eget vetenskapligt område inom datavetenskapen.
(Ants språkliga design får mig att tänka på språket RPG fritt format, där varje sats måste avslutas med semikolon. Man kan ana hur språkdesignerna bör ha influerats av samtida språk som C och Pascal. Det intressanta är dock att till skillnad från RPG så fyller semikolonet en funktion i båda dessa språk eftersom man kan ha flera satser per rad. I RPG är detta inte tillåtet: här gäller en sats, en rad. Därför blir semikolonet helt onödigt. )
Det var därför med blandade känslor jag började använda Maven i mitt nuvarande projekt. I likhet med Ant så skriver man i Maven också sina byggfiler i XML. I stället för build.xml kallas de för pom.xml. Här slutar dock likheterna. Ant ger dig inget mer, du måste själv bestämma projektstruktur och hela faderullan. Det slutar oftast i ett gytter av intrikata beroende mellan inkluderade byggfiler och luddiga targets.
Maven har istället standardiserat hur byggena ska genomföras. Naturligtvis går det att anpassa mot t.ex. gamla Antbyggen om man vill, men det blir knöligt. Mitt tips är att följa Mavenkonventionen så långt det är möjligt. Ett bygge genomgår ett antal faser som är beroende av varandra. Skriver man t.ex. ”mvn package” för att skapa byggets artifakt så genomförs alla tidigare faser som t.ex. compile och test.
Maven har direkt stöd för nästlade moduler (projekt) som i t.ex. Netbeans. Tyvärr har inte alla verktyg detta (t.ex. Eclipse). Därför bör man för största IDE-kompatibilitet försöka köra en platt struktur. Varje modul har en sk. pom.xml-fil (Project Object Model). I denna specificeras t.ex. vad modulen heter, vilken version den har, vad den producerar för artifakt, om modulen är beroende av andra moduler (interna som externa).
Varje modul producerar högst en artifakt . I Maven finns inbyggt stöd för de vanligaste artifakterna (WAR, EJB, JAR etc) i form av pluggar som laddas ner automatiskt när de refereras. Pluggarna hjälper till att skapa artifakten genom att bl.a. generera deskriptorer och inkludera beroenden. Det enda man behöver tänka på är att följa Mavens katalogstruktur, men även detta får man hjälp med.
Varje plugg kan konfigureras för exakt bestämma hur genererad artifakt ska se ut. Exempelvis bestämmer man i maven-ear-plugin vilken kontextrot man vill ha, om man inte nöjer sig med default. Maven ser till att generara nödvändig information i application.xml för detta.
För varje beroende (t.ex. Hibernate, Log4J etc) man har i sin modul så specificerar man dessa genom namn, version och scope. T.ex. Hibernate, version 3.23 och scope test innebär att Maven lägger Hibernate version 3.23 till classpath vid körning av enhetstester. Rätt beroende tankas automatiskt hem från ett centralt Mavenarkiv. På det här sättet får man en bra versionshantering av sina beroenden. Alla i projektet kommer att utveckla mot samma version.
Vilka arkiv som ska användas kan man styra. Man kan sätta upp egna speglar och proxies mot det centrala arkivet eller egna företags-arkiv. Varje användare har dessutom ett lokalt arkiv i sin hemkatalog där alla beroende cacheas. Utveckling kan alltså ske offline.
Det är att rekommendera att man som företag sätter upp en proxy mot det centrala Maven arkivet. När beroenden tankas hem från det centrala arkivet kommer de automatiskt att lagras på proxyn. På så sätt säkerställs att företaget har direkt tillgång till alla refererade beroenden. Notera att beroenden normalt är transitiva, t.ex. Hibernate beror i sin tur på Log4J. Som tur är behöver du inte bry dig om det, utan Maven sköter det åt dig genom att automatiskt tanka hem transitiva beroenden.
Maven hjälper dig inte bara med att kompilera ditt projekt, köra tester och generera dokumentation, utan du kan också få hjälp med att driftsätta. Pluggen cargo-maven2-plugin kan t.ex. fjärrdriftsätta mot en JBoss-server när man skriver ”mvn install”. Vill man så kan få Maven (genom cargo-maven2-plugin) att tanka hem, zippa upp och start en JBoss om den inte redan finns.
Vad blir slutsatsen då? Det låter ju som Maven är ett helt underbart byggverktyg. Och det är det oftast. Mavens absolut största nackdel är att det är så **** odokumenterat. Maven är en enda stor samling insticksprogram som var och en är separat dokumenterade. De mindre änvända insticken är mycket sparsamt dokumenterade. Det finns väldigt få centrala källor att gå till, utan mycket ligger utspritt på webben. I början känns Mavenrymden väldigt kaotisk.
När jag säger Maven så menar jag dessutom Maven 2. På nätet finns en del information om Maven, men i bland avser den Maven 1. De två versionerna skiljer sig relativt mycket. I början kan det vara lite förvillande.
Räkna också med en del buggar vad det gäller de mindre frekvent använda funktionerna. Bara i dag har jag sprungit på två stycken: den ena som har med arv av profiler att göra verkar det ännu inte finnas nån fix för och den andra som har med filterhantering i maven-assembly-plugin att göra fanns det en fix i version 2.2-beta-2-SNAPSHOT av pluginnen. För att avhjälpa det senare problemet behövde jag bara specificera rätt version i pommen.
Tyvärr så känns det inte helt stabilt att förlita affärskritisk verksamhet på en snapshot. Nästa dag kan en ny bugg som fallerar bygget vara introducerad i snapshoten. Visst, i de lägena går det faktiskt att specificera en specifik snapshot, t.ex. 2.2-beta-2-20070808.014358-13.
Hur som helst. Maven är trots nackdelarna ett så stort steg i rätt riktning att jag inte skulle tveka att använda det i nästa projekt. Men om du eller ditt företag ska gå över till Maven räkna med en tuff startsträcka. Jag rekommenderar ha en Maven-expert nära till hands.
