Tips & Tricks – Meer met Maven

In elke editie zal Robert Scholte een probleem voorleggen en deze oplossen met behulp van Apache Maven om meer inzicht te geven in Maven zelf en de vele beschikbare plugins.

Hoe wordt Maven via de commandline het vaakst aangeroepen en waarom? Ik vrees, dat het overgrote deel van de gebruikers deze vraag zal beantwoorden met: ‘clean install’. De reden heeft waarschijnlijk te maken met ervaringen uit het verleden met Ant of omdat het zo is aangeleerd door collega’s,  oftewel: voor waar aangenomen zonder exact te begrijpen wat er gebeurt of wat de gevolgen zijn.

Laten we beginnen met de zin en onzin van ‘clean’.  Wat er tijdens deze phase gebeurt is uiteindelijk niets meer dan de target-directory opruimen en verwijderen. Dus voor degene die nog met een ‘initialize’ hun IDE op orde moet maken: daar heeft ‘clean’ geen effect, aangezien dit soort bestanden veelal in de basedirectory van het project weggeschreven worden en niet in de target-directory.

Al sinds het begin van Maven proberen de meeste plugins te voorspellen of ze iets moeten doen, bijvoorbeeld compileren. Als alle gecompileerde bestanden nieuwer zijn dan de bijbehorende source-files is er geen reden om opnieuw te compileren. Als er wel een source-bestand was aangepast, dan werd alleen dat bestand gecompileerd. De ‘clean’ leek voornamelijk zinvol als je source files ging hernoemen of verplaatsen, omdat anders de oude varianten nog steeds tussen de gecompileerde classes bleven staan. Met Apache Maven Compiler Plugin 3.0 is een start gemaakt met het ondersteunen van incremental builds, waardoor de noodzakelijke ‘clean’ bij de eerdergenoemde voorbeelden niet meer nodig is.

Kortom, op een ontwikkelomgeving is een ‘clean’ veelal overbodig (of neem anders contact op met het plugin ontwikkelteam), en zorgt ervoor dat het bouwen van een project meer tijd kost.

Dan de phase ‘install’,  waarbij bestanden gekopieerd worden naar je lokale repository. Dat was met Maven2 soms nog noodzakelijk voor multimodule projecten. Met Maven3 is dit sterk verbeterd en kan Maven onderlinge relaties gebruiken voor dependency resolution zonder uitstap naar de lokale repository.

Een nadeel dat kleeft aan de ‘install’ is dat jouw repository er ineens anders uitziet dan die van je collega’s, met als gevolg de gevleugelde uitspraak “Works on my machine!”. Je mag van een collega geen extra handelingen verwachten om een project te kunnen bouwen. Vandaar dat ik liever ‘deploy’ aanroep. Of nog beter ‘verify’, waarbij vervolgens een buildserver de ‘deploy’ voor zijn rekening neemt.

‘verify’ is de laatste phase vlak vóór ‘install’, waarbij de resultaten van eventuele integratie-testen gecontroleerd worden. Zelfs als een project  geen integratie-testen heeft, is het verstandig om je aan te leren ‘mvn verify’ aan te roepen in plaats van ‘mvn package’, voor het geval er ineens wel integratie-testen zijn.

Dan is natuurlijk de vraag: wanneer mag ik wel ‘install’ gebruiken? Dat is in situaties waarbij je één van de dependencies van je project eerst zelf wilt aanpassen en testen, hetzij in verband met een bug of nieuwe feature. Uiteraard schrijf je een unittest bij jouw aanpassing, maar graag wil je het ook bevestigd hebben met jouw eigen project dat afhankelijk is van deze aanpassing. Zo’n situatie rechtvaardigt ‘install’, maar over het algemeen wil je Maven aanroepen met:

‘mvn verify’