[Tutorial] Eine Einführung in Maven – Teil 2 / 2

Im 1. Teil des Tutorials haben wir bereits gelernt, wie man ein Maven Projekt erstellt. Auch was Maven ist, wissen wir bereits.

In diesem 2. Teil soll es nun darum gehen, wie wir Maven Projekte konfigurieren und richtig einsetzen.

 

Die pom.xml Konfigurationsdatei

Maven erzeugt für jedes Projekt & jedes Submodule eine Konfigurationsdatei: die pom.xml .

In dieser wird alles wichtige, wie die verwendeten libraries (dependencies), bis zur Java Version hinterlegt.

Standardmäßig sieht diese pom.xml nach der Erstellung wie folgt aus:

 

Die Tags <project> … </project> schließen die ganze Konfiguration ein.

Interessant werden für uns in diesem Fall aber erst diese Zeilen:

 

Hier stehen eure groupID (die Hersteller ComID, die ihr euch ausdenken könnt, z.B. de.jukusoft – weitere Informationen dazu gibts weiter unten), die artifactID (also euer Software Produkt Name), sowie die Version, z.B. “1.0.0”, falls es sich um eine finale Version handelt oder “1.0.0-SNAPSHOT”, falls die Version noch nicht final ist, sondern eher einen Schnappschuss (Snapshot) der aktuellen Entwicklungen darstellt, dies könnte z.B. ein Nightly Build sein. Im 1. Teil dieses Tutorials gab es bereits eine genauere Erklärung hierzu. Die Maven Naming Conventions findet ihr hier.

 

Hinweis: Was ist eine comID?

Da einige den Begriff der comID noch nicht kennen, hier eine kurze Erklärung:

Die meisten TLD Domains endeten (früher) mit .com und unter Java wurden für die package Naming Conventions meist die Domain des Herstellers einfach umgedreht, also z.B. example.com –>com.example . Deshalb nannte man sie comID. Man kann aber jede beliebige Endung verwenden, also auch .de usw. Um selbst einmal libraries / dependencies im Maven Central Repository veröffentlichen zu können, geht der Betreiber Sonatype sogar soweit, dass man die TLD Domain besitzen muss (WHOIS Record Check). Solange man aber keine libraries in diesem Maven Central Repository hochladen will, muss man nicht im Besitz dieser Domain sein.

 

Abhängigkeiten (Libraries) ins Projekt einbinden

Viele der heutigen Software-Projekte bauen auf anderen libraries (Programm Bibliotheken) auf, damit die Entwickler nicht immer das Rad neu erfinden müssen (was in der Wirtschaft auch viel zu teuer wäre und zu lange dauern würde). In einem normalen IDE Projekt ohne Maven müsste man die Libraries aus dem Internet raussuchen, herunterladen und extra in den Projekt-Einstellungen einbinden. Problematisch wird das ganze, wenn mehrere Leute im Team an dem Projekt arbeiten und somit jeder von ihnen die selben Schritte unternehmen müsste, bis er endlich mit entwickeln kann. Hier setzt Maven an:

Wir sagen Maven einfach, was wir für dieses Projekt brauchen (die Abhängigkeiten) und Maven kümmert sich selbst darum, dass es da ist und dass wir es verwenden können.

Alle Abhängigkeiten kommen zwischen die <dependencies> … </dependencies> Tags. In diese kommen nochmal für jede Abhängigkeit eigene <dependencie> … </dependencie> Tags wo man dann ihre groupID, artifactID und ihre Version angeben muss.

Hier einmal ein Beispiel:

In diesem Fall haben wir 2 libraries eingebunden:

  • die Logger Library log4j
  • eine JSON Library zum Parsen und Erstellen von JSON Objekten / Strings

 

Solange Maven diese libraries noch nicht gefunden oder heruntergeladen hat, werden diese in den meisten IDEs (z.B. IntelliJ) rot angezeigt. Wenn ihr Auto Import aktiviert habt (siehe 1. Teil des Tutorials), lädt Maven die Libraries jetzt automatisch im Hintergrund herunter, ansonsten erst beim nächsten Build (mvn clean install).

 

Wo kommen diese ganzen dependencies überhaupt her? Wie findet Maven sie und lädt sie herunter?

Sicherlich habt ihr euch schon gefragt, wo ich die groupIDs, artifactIDs und Versionen im Abschnitt oben drüber wohl her habe und woher Maven jetzt weiß, wo er die JAR Dateien herunterladen müsst.

Dafür gibt es das sog. Maven Central Repostory. Die meisten Softwareentwickler von kostenfreien und hochwertigen (Open Source) libraries laden ihre libraries dort hoch, um euch einen schnellen Zugriff über Maven zu gewähren. Von dort lädt Maven sie dann auch direkt runter. Wenn ihr also jetzt auf http://search.maven.org geht, findet ihr ein Suchfeld vor, bei dem ihr nach libraries suchen könnt. Ihr könnt dort sowohl Stichwörter, wie JSON, aber auch groupIDs oder artifactIDs angeben.

Search Maven Central

 

Wenn ihr also wie in diesem Fall nach “JSON” sucht, findet ihr alle libraries, die irgendwie JSON im Namen tragen. Übrigens beachtet das Maven Central Repository keine Groß- & Kleinschreibung, da alle libraries nur mit kleinen Buchstaben vorkommen.

Maven Central JSON Search

Wenn ihr jetzt rechts in der Spalte “Version” auf die erste Versionsnummer klickt, erhaltet ihr alle Informationen zur neuesten Version dieser library. Unter “all” könnt ihr euch auch alle weiteren Versionen anschauen. Ich habe in diesem Beispiel einmal auf die neueste org.json library geklickt und gelange damit auf diese Seite:

Maven Central JSON library

Links findet ihr unter “Dependencie Information” sogar fertige Snippets, die ihr nur noch in eure pom.xml zwischen die <dependencies> … </dependencies> Tags einfügen müsst.

Bei org.json sähe das Snippet also wie folgt aus:

 

Maven Projekte direkt aus der IDE (z.B. IntelliJ) ausführen

Wenn ihr in der IDE eurer Wahl, in meinem Fall IntelliJ, nun euer Maven Projekt bauen (kompilieren) und ausführen wollt, wird standardmäßig noch der normale IntelliJ Build ausgeführt, wir wollen den Build aber nicht von der IDE, sondern von Maven steuern lassen. Dazu geht zuerst in eure Run Configuration (IntelliJ: Menü –> Run –> Edit Configurations). Danach sollte sich bei euch ein Fenster öffnen, z.B. wie folgt:

IntelliJ Run Configuration

 

Als nächstes klicken wir auf das Plus und wählen dann “Application” aus:

IntelliJ Create Run Configuration

 

Danach sollte ein Fenster erscheinen:

Maven Run Configuration

Hier gebt ihr oben zuerst einen Namen für die Run Configuration ein (1), z.B. einfach “App”. Den Namen könnt ihr beliebig wählen. Danach wählt ihr eure Main Klasse aus (2), indem ihr auf den Button klickt und aus der Auswahl eure Main Klasse heraussucht. Als nächstes müssen wir Maven selbst noch einbinden, indem wir unten das “Make” raus löschen (Mit Maus drauf und dann auf das Minus Symbol klicken) und dann auf das Plus Symbol klicken, um eine neue Anweisung hinzuzufügen.

Maven Run Configuration

Hier wählen wir dann “Run Maven Goal” aus. Als nächstes erscheint ein Dialog, wo ihr “clean install” eingeben müsst. Beides sind Maven “goals”, also Aufgaben, die Maven nacheinander ausführt. Das clean räumt zuerst die alten Builds (alte .class Dateien usw.) auf und das install kompiliert die ganzen Java Klassen, führt, falls möglich, die JUnit Tests aus (oder was ihr konfiguriert habt) und deployed die fertige JAR in euer lokales Maven Repostory. Nach dem Maven ausgeführt wurde, wird direkt die Applikation gestartet. Diesen ganzen Prozess könnt ihr dann Starten, indem ihr in Eclipse oder IntelliJ auf das Play Symbol (2. Bild) klickt.

 

Run Maven Goal

Start Application

 

Maven Plugins

Jetzt solltet ihr also nicht nur in der Lage sein, eigene Maven Projekte zu erstellen, sondern auch libraries / Abhängigkeiten hinzuzufügen. Zu guter letzt wollen wir uns noch kurz den Maven Plugins zu wenden, wobei ich vermutlich einmal in einem anderem Artikel genauer darauf eingehen würde, da dies sonst hier den Rahmen sprengen würde.

Man kann in der pom.xml auch Maven Plugins konfigurieren, die zu einem bestimmten Scope / Goal (z.B. clean, package, test oder install) ausgeführt werden.

Dazu gibt es die <build> … </build> Tags. In diesem gibt es wiederum die <plugins> … </plugins> Tags, wo alle Plugin Konfigurationen rein gehören. In diesem Beispiel wollen wir einmal 2 Plugins einbinden:

  • ein Compiler Plugin, um die Java Version festzulegen
  • ein JAR Plugin, damit beim Build automatisch eine JAR Datei erstellt wird

 

Unsere komplette pom.xml sieht dann wie folgt aus:

 

Zum 1. Plugin (maven-compiler-plugin)

Hier legen wir lediglich die Java Version 1.8, also Java 8 fest. Hier wird zwischen der Source Version und der Target Version unterschieden, wobei target version >= source version gelten muss. Eine Java Klasse, die für Java 8 (source) kompiliert wurde, läuft eben nicht unter Java 7 (target). Wenn wir in der Klasse aber nur Java 7 Features nutzen würden, könnten wir die source Version auf 1.7 setzen, damit die Applikation auch Java 7 unterstützt. Die target Version kann weiterhin auf 1.8 bleiben, wenn wir zwar mit Java 7 kompilieren, aber in unserem Fall unter Java 8 ausführen wollen.

 

Zum 2. Plugin (maven-jar-plugin)

Dieses Plugin erstellt automatisch eine JAR Datei aus all euren Klassen, sodass ihr die Applikation später direkt mit “java -jar <JAR Datei>.jar” ausführt könnt. Schließlich will man nicht die ganzen .class Dateien einzeln übertragen. Außerdem enthält eine JAR Datei eine MANIFEST Datei, in welcher u.a. die Main Klasse festgelegt ist.

In unserer Konfiguration geben wir außerdem an, dass wir einen Classpath (das ist der Pfad, an dem Java nach weiteren .class oder .jar Dateien suchen darf) festlegen wollen und Java Klassen / JAR Archive aus dem Ordner “lib” (falls er denn existiert) laden darf. Außerdem geben wir hier unsere Main Klasse an, die beim Starten der JAR Datei (geht auch mit Doppelklick, solange es keine Konsolenanwendung ist – wie bei einer .exe) aufgerufen wird.

 

Falls ihr wieder Fragen, Kritik oder Anregungen mitteilen wollt, könnt ihr dies wie immer gerne in den Kommentaren tun.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.