Tutorial: Build-Frameworks: Maven und Gradle

Was sind Build-Frameworks?

Wie der Name schon vermuten lässt, sind Build-Frameworks einfach gesagt Frameworks, die den Build-Prozess einer Software u.a. vereinfachen, automatisieren oder manipulieren lassen.

Beispiel zur Motivation

Angenommen man schreibt ein Java-Programm und möchte externe Bibliotheken benutzen. Man könnte diese natürlich händisch herunterladen und in seinen Projektordner kopieren. Aber was, wenn diese Bibliothek nun wiederum Abhängigkeiten hat, also ebenfalls externe Bibliotheken benötigt, die heruntergeladen werden müssen? Was, wenn in einem wachsenden Projekt hunderte Bibliotheken verwendet werden? Und was, wenn plötzlich ein anderer Entwickler am selben Projekt beteiligt ist? Dieser müsste dann ebenfalls alle Bibliotheken händisch einbinden und zwar in der korrekten Version. Dass das nicht praktikabel ist, liegt auf der Hand. Hierfür bieten Build-Frameworks, wie Maven und Gradle für Java, eine Lösung. Natürlich gibt es noch viele weitere Möglichkeiten (z.B. build-Skripte), die sich durch den Einsatz solcher Frameworks bieten, auf die jedoch an anderer Stelle detailliert eingegangen wird (siehe weiterführende Links).

Maven und Gradle

Beide Build-Frameworks stammen aus dem Java-Umfeld, wobei Maven ausschließlich für Java-Projekte eingesetzt wird und Gradle neben Java z.B. auch Groovy unterstützt. Ähnliche Frameworks gibt es auch für andere Programmiersprachen. Die gängigsten Java-IDEs, wie z.B. Eclipse, IntelliJ IDEA und NetBeans, bieten dabei direkte Unterstützung für Maven und Gradle an.

Maven

In Maven wird der Build-Prozess in der pom.xml-Datei konfiguriert, dem sogenannten Project Object Model (POM), welche im root-Ordner des Java-Projektes abgelegt wird. Nach der Maven-Installation kann die pom.xml über den Konsolenbefehl mvn archetype:generate im root-Ordner des Java-Projektes erzeugt werden. Nach Eingabe der relevanten Daten existiert die pom.xml und die Entwicklung kann beginnen.

Die letzten drei Zeilen beschreiben dabei grundlegend das Projekt. In dieser Datei erfolgt sämtliche Build-Konfiguration, z.B. auch das Einbinden externer Java-Bibliotheken. Dazu kann im zentralen Maven-Repository (https://mvnrepository.com) nach Bibliotheken gesucht werden. Das Repository stellt Code-Schnipsel bereit, die dann nur noch in das Root-Element der pom.xml kopiert werden müssen.

Screenshot einer Seite des Maven-Repositories

So sieht eine Externe Bibliothek im zentralen Maven-Repository aus (siehe https://mvnrepository.com/artifact/org.junit.jupiter/junit-jupiter-api/5.3.1)

Die fertige pom.xml-Datei mit der neuen Bibliothek:

Aus der Konsole heraus kann nun mit mvn compile das Projekt kompiliert werden. Dabei werden die externen Bibliotheken geladen und lokal im Home-Verzeichnis des Benutzers im .m2-Ordner abgelegt. Maven schaut dann beim nächsten Kompilieren zuerst dort nach den Abhängigkeiten und lädt dann nur noch nach Bedarf weitere Bibliotheken aus dem zentralen Repository. Ist die Bibliothek einmal in der pom.xml hinterlegt, muss einem anderen Entwickler nur noch diese Datei gegeben werden und alle für das Projekt notwendigen Bibliotheken in der richtigen Version werden automatisch heruntergeladen und eingebunden.

Gradle

Gradle ist etwas neuer, baut jedoch auf Maven auf, sodass ebenfalls das zentrale Maven-Repository verwendet werden kann und statt xml-Code eben gradle-Code generiert wird. Die Build-Konfiguration erfolgt hier nicht in der pom.xml-Datei, sondern in der build.gradle-Datei. Das Pendant zur pom.xml sieht dann bei Gradle wie folgt aus:

Weitere Unterschiede zwischen beiden Frameworks werden in den weiterführenden Links erläutert.

Weiterführende Links

Gradle:

Maven:

Maven vs. Gradle:

 

Schreibe einen Kommentar

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