De filosofie van Maven

 
26 januari 2008

Toen ik voor het eerst kennis maakte met Maven versie 1 was ik niet echt onder de indruk. Het was traag, maakte ontzettend veel gebruik van XML (het maakte zelfs gebruik van Jelly een XML script taal) en de documentatie was schaars. Maar met de komst van Maven versie 2 veranderde er een hoop.

Maven 1 en 2
Maven 2 is een complete herbouw van Maven 1 in Java. Tijdens de bouw van de eerste versie kreeg men steeds meer een beter beeld van waar men met het product in de toekomst heen willen. Men is een nieuwe versie gestart die men in Java ging bouwen omdat de vorige versie met snelheid problemen te kampen had. Tevens had men ingezien dat men liever meer standaarden had dan configuratie. Dit is de essentie van Maven 2.

Project object model
Maven maakt gebruik van een klein XML bestand dat je project beschrijft. In dit kleine bestand, die hoogstens een paar kilobyte groot wordt bij een groot project, wordt Maven alleen mee geïnstrueerd om bepaalde plugins te draaien om specifieke onderdelen in de bouw van je applicatie tot stand te brengen.
Als je maven start met het mvn compile commando dan zoekt hij naar het bestand genaamd pom.xml en zal hij alle sourcecode compileren.
POM staat voor Project Object Model. Dit is het hart van Maven. Hieronder is een klein voorbeeld van de minimale pom die nodig is om je project te laten werken met Maven:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">

  <modelVersion>4.0.0</modelVersion>
  <groupId>com.mycompany.app</groupId>
  <artifactId>my-app</artifactId>
  <version>1.0-SNAPSHOT</version>
  <packaging>jar</packaging>
</project>

Zo zegt de tag ‘packaging’ wat Maven moet doen als de goal (taak om uit te voeren) ‘package’ gestart wordt. Bij de invulling jar zal Maven alle gecompileerde classes in een jar inpakken. Mocht men een ear willen bouwen vult men hier uiteraard ear in en zo zijn er nog een heleboel andere manieren van inpakken.

Directory structuur
Alleen een pom.xml neerzetten in de root van je project zal niet voldoende zijn om Maven je project te laten bouwen. Maven moet wel je Java bestanden kunnen vinden om deze te compileren.
Standaard zal Maven kijken in

src/main/java

voor je sourcecode. Zo verwacht hij dat je junit tests staat onder:

src/test/java

Er zijn uiteraard nog veel meer directories nodig; afhankelijk van wat je gebruikt binnen je project. Een volledige lijst met directory structuren kan je op de website van Maven vinden.
Als je per se wilt is het mogelijk om deze paden te veranderen, het is uiteraard veel eenvoudiger om je te houden aan de Maven standaarden want dan hoef je bijna niets aan te geven.

Repository
Wat ook standaard is binnen Maven is de repository. Er is een lokale repository waar alle ingepakte bestanden (voornamelijk jar bestanden) worden neer gezet. Hierbij wordt gebruik gemaakt van de groupId en artifactId die in de pom.xml vermeld staan. De groupId zal over het algemeen de naam van de leverancier zijn; de website achterste voren. Bijvoorbeeld: org.springframework. ArtifactId is de naam van de jar bijvoorbeeld: spring-core. De versie nummer die in de pom staat wordt hierbij ook gebruikt. Zo wordt de naam van een jar altijd opgesteld met behulp van de artifactId en versie om versie problemen tegen te gaan.
Zo is er niet alleen een lokale repository waar alle jar bestanden terecht komen, maar ook een central repository. Als je Maven voor het eerst gebruikt zal hij voor elk commando dat men op hem af vuurt deze plugins eerst moeten ophalen vanuit de central repository. Als Maven deze ophaalt wordt deze meteen opgeslagen in je lokale repository voor later gebruik.
Het mooie van de repository van Maven is dat je Maven ook kan vertellen om andere repositories te gebruiken naast de centrale repsoitory. Men kan dus bijvoorbeeld een corporate repository opzetten die alleen gebruikt kan worden door mensen die toegang hebben tot het netwerk van het bedrijf.
Er is overigens een website om te kunnen zoeken over de centrale repository van Maven.

Build lifecycle
Het feit dat Maven poogt (het is nog niet helemaal perfect) om de build lifecycle te standaardiseren is een van de redenen dat ik deze tool ben gaan gebruiken.
De build lifecycle beschrijft alle stappen die moeten gebeuren om een project op te leveren, van compileren tot inpakken. Dus als men het volgende commando intikt:

mvn package

Dan zal Maven alle stappen die ervoor vallen eerst uitvoeren zodat deze taak gedaan kan worden. Deze lijst is overigens niet klein de lijst bestaat uit 21 stappen. Er zijn 14 stappen voordat ‘package’ uitgevoerd gaat worden. Dit klinkt overigens alsof het ontzettend lang gaat duren voordat Maven klaar is met het bouwen van je project maar dit is zeer zeker niet het geval.
Een hoop mensen zullen nu wel denken: Wat is nou het voordeel dat de build lifecycle gestandaardiseerd is? Een van mijn ergernissen bij het gebruik van ANT was dat het een hoop tijd kostte om een script te maken die alles deed om je project te bouwen. Als ik dan een script geschreven had moest ik alle individuele taken een naam geven. Vaak noemde ik de taak die alles deed ‘build-all’. Dan ging je over naar een ander project en had iemand al een script geschreven en noemde deze ‘compile’. Zo was er geen standaard aanroep voor ANT om alles te laten doen. Dit betekend dat je altijd de build script na moet lezen en echt moet leren kennen om er mee te werken.

Nadelen
Ik ben een Maven evangelist maar zal hier in alle eerlijkheid zeggen dat er ook nadelen aan kleven om zo goed als alles standaard te maken. Wat ik al een beetje aangaf: als je wilt afwijken van de standaard dan kost het even wat meer moeite.
Zo werkt Maven standaard met JDK 1.4. Als je dus gebruik wilt maken van JDK 1.5 (of hoger) dan moet je Maven configureren.
De volgende configuratie moet worden toegevoegd aan de pom om te compileren met JDK 1.5:

<project xmlns="http://maven.apache.org/POM/4.0.0" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">

  ...

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <configuration>
          <source>1.5</source>
          <target>1.5</target>
        </configuration>
      </plugin>
    <plugins>
  <build>
</project>

Zoals te zien is ziet dit er omslachtig uit. Hier staat, vertaald: Voor het bouwen moet een andere configuratie gebruikt worden voor de compiler plugin.

Andere voordelen
Er is een zeer grote waslijst aan andere redenen om wel gebruik te maken van Maven. Een van de, in mijn ogen, belangrijkste feature is zijn transitieve afhankelijkheden (transitive dependencies) maar hierover blog ik de volgende keer.


Werken met ?
Kijk dan bij onze mogelijkheden voor zowel starters als ervaren engineers.


Categorieën: Development

Tags: , ,


Reactie

  • Erwin Wernsen schreef:

    We hebben recent een website opgezet waarmee het mogelijk is om over meerdere, publieke maven repositories te zoeken. Op http://www.mavenbrowser.com kun je zoeken naar artifacts in de centrale repository maar ook in de repositories van JBoss, Atlasssian, Java.net, Codehaus en nog veel meer. Zo blijken er aardig wat kleinere repositories te zijn met soms hele specifieke maar heel handige artifacts!

    Daarnaast proberen we zoveel mogelijk en zo compleet mogelijke informatie te verschaffen over de artifacts zoals de beschikbare versies, de dependencies en of de javadoc en de sources van het artifact ook in de repository aanwezig zijn. Dit laatste kan erg handig zijn bij het kiezen van de versie voor je artifact.

    Nu zijn we bezig met een pagina waarop je snel en makkelijk kan controleren of de dependencies in je POM nog up-to-date zijn. Door de dependencies uit je POM in te geven genereren wij een overzichtelijk lijstje met de artifacts en of er nieuwere versies beschikbaar zijn.

    Zoals gezegd, een en ander is nog heel nieuw en in ontwikkeling maar ik ben benieuwd wat jij er van vindt!

    Geplaatst op 06 augustus 2008 om 15:21 Permalink