Ameise gegen Maven gegen Gradle

Dieser Artikel ist Teil einer Reihe: • Einführung in Gradle

• Ant vs Maven vs Gradle (aktueller Artikel) • Schreiben von benutzerdefinierten Gradle-Plugins

• Erstellen eines Fat Jar in Gradle

1. Einleitung

In diesem Artikel werden drei Java-Build-Automatisierungswerkzeuge untersucht, die das JVM-Ökosystem dominierten - Ant, Maven und Gradle .

Wir werden jeden von ihnen vorstellen und untersuchen, wie sich Java Build-Automatisierungstools entwickelt haben.

2. Apache Ant

Am Anfang war Make das einzige Tool zur Build-Automatisierung, das über einheimische Lösungen hinaus verfügbar war . Make gibt es seit 1976 und als solches wurde es in den frühen Java-Jahren zum Erstellen von Java-Anwendungen verwendet.

Viele Konventionen von C-Programmen passten jedoch nicht in das Java-Ökosystem, sodass Ant mit der Zeit die bessere Alternative übernahm.

Apache Ant („Another Neat Tool“) ist eine Java-Bibliothek zur Automatisierung von Erstellungsprozessen für Java-Anwendungen . Darüber hinaus kann Ant zum Erstellen von Nicht-Java-Anwendungen verwendet werden. Es war ursprünglich Teil der Apache Tomcat-Codebasis und wurde im Jahr 2000 als eigenständiges Projekt veröffentlicht.

In vielen Aspekten ist Ant Make sehr ähnlich und einfach genug, damit jeder ohne besondere Voraussetzungen damit beginnen kann. Ant-Build-Dateien sind in XML geschrieben und werden üblicherweise als build.xml bezeichnet .

Verschiedene Phasen eines Erstellungsprozesses werden als „Ziele“ bezeichnet.

Hier ist ein Beispiel einer build.xml- Datei für ein einfaches Java-Projekt mit der HelloWorld- Hauptklasse:

Diese Build-Datei definiert vier Ziele: Bereinigen , Kompilieren , JAR und Ausführen . Zum Beispiel können wir den Code kompilieren, indem wir Folgendes ausführen:

ant compile

Dies löst zuerst die Zielbereinigung aus , wodurch das Verzeichnis "Klassen" gelöscht wird. Danach wird das Ziel der Kompilierung wird das Verzeichnis neu erstellen und die src - Ordner in kompilieren.

Der Hauptvorteil von Ant ist seine Flexibilität. Ant legt keine Codierungskonventionen oder Projektstrukturen fest. Folglich bedeutet dies, dass Ant von Entwicklern verlangt, alle Befehle selbst zu schreiben, was manchmal zu riesigen XML-Build-Dateien führt, die schwer zu warten sind.

Da es keine Konventionen gibt, bedeutet das Wissen um Ant nicht, dass wir eine Ant-Build-Datei schnell verstehen. Es wird wahrscheinlich einige Zeit dauern, bis Sie sich an eine unbekannte Ant-Datei gewöhnt haben, was im Vergleich zu den anderen, neueren Tools ein Nachteil ist.

Zunächst hatte Ant keine integrierte Unterstützung für das Abhängigkeitsmanagement. Da das Abhängigkeitsmanagement in den späteren Jahren jedoch zu einem Muss wurde, wurde Apache Ivy als Teilprojekt des Apache Ant-Projekts entwickelt. Es ist in Apache Ant integriert und folgt denselben Designprinzipien.

Die anfänglichen Ant-Einschränkungen aufgrund fehlender integrierter Unterstützung für das Abhängigkeitsmanagement und Frustrationen bei der Arbeit mit nicht verwaltbaren XML-Build-Dateien führten jedoch zur Erstellung von Maven.

3. Apache Maven

Apache Maven ist ein Abhängigkeitsmanagement- und Build-Automatisierungstool, das hauptsächlich für Java-Anwendungen verwendet wird. Maven verwendet weiterhin XML-Dateien wie Ant, jedoch auf eine viel einfachere Art und Weise. Der Name des Spiels hier ist Konvention über Konfiguration.

Während Ant Flexibilität bietet und erfordert, dass alles von Grund auf neu geschrieben wird, verlässt sich Maven auf Konventionen und stellt vordefinierte Befehle (Ziele) bereit.

Einfach ausgedrückt, Maven ermöglicht es uns, uns auf das zu konzentrieren, was unser Build tun soll, und gibt uns den Rahmen dafür. Ein weiterer positiver Aspekt von Maven war die integrierte Unterstützung für das Abhängigkeitsmanagement.

Die Konfigurationsdatei von Maven, die Anweisungen zum Erstellen und zur Verwaltung von Abhängigkeiten enthält, heißt üblicherweise pom.xml . Darüber hinaus schreibt Maven eine strenge Projektstruktur vor, während Ant auch dort Flexibilität bietet.

Hier ist ein Beispiel für eine pom.xml- Datei für dasselbe einfache Java-Projekt mit der HelloWorld- Hauptklasse von zuvor:

 4.0.0 baeldung mavenExample 0.0.1-SNAPSHOT Maven example   junit junit 4.12 test   

Jetzt wurde jedoch auch die Projektstruktur standardisiert und entspricht den Maven-Konventionen:

+---src | +---main | | +---java | | | \---com | | | \---baeldung | | | \---maven | | | HelloWorld.java | | | | | \---resources | \---test | +---java | \---resources

Im Gegensatz zu Ant müssen nicht alle Phasen des Erstellungsprozesses manuell definiert werden. Stattdessen können wir einfach die integrierten Befehle von Maven aufrufen.

Zum Beispiel können wir den Code kompilieren, indem wir Folgendes ausführen:

mvn compile

Wie auf offiziellen Seiten erwähnt, kann Maven im Kern als Plugin-Ausführungsframework betrachtet werden, da alle Arbeiten von Plugins ausgeführt werden. Maven unterstützt eine Vielzahl verfügbarer Plugins, von denen jedes zusätzlich konfiguriert werden kann.

Einer der verfügbaren Plugins ist Apache Maven Dependency Plugin , das eine hat copy-Abhängigkeiten Ziel , dass unsere Abhängigkeiten in einem bestimmten Verzeichnis kopiert.

Um dieses Plugin in Aktion zu zeigen, fügen wir dieses Plugin in unsere Datei pom.xml ein und konfigurieren ein Ausgabeverzeichnis für unsere Abhängigkeiten:

   org.apache.maven.plugins maven-dependency-plugin   copy-dependencies package  copy-dependencies   target/dependencies       

Dieses Plugin wird in einer Paketphase ausgeführt. Wenn wir also Folgendes ausführen:

mvn package

Wir werden dieses Plugin ausführen und Abhängigkeiten in den Ordner target / dependencies kopieren.

Es gibt auch einen Artikel darüber, wie man eine ausführbare JAR mit verschiedenen Maven-Plugins erstellt. Eine detaillierte Übersicht über Maven finden Sie in diesem Leitfaden zu Maven, in dem einige der wichtigsten Funktionen von Maven erläutert werden.

Maven wurde sehr beliebt, da Build-Dateien jetzt standardisiert waren und die Verwaltung von Build-Dateien im Vergleich zu Ant erheblich weniger Zeit in Anspruch nahm. Obwohl Maven-Konfigurationsdateien standardisierter als Ant-Dateien sind, werden sie immer noch groß und umständlich.

Mavens strenge Konventionen haben den Preis, viel weniger flexibel zu sein als Ant. Die Zielanpassung ist sehr schwierig, daher ist das Schreiben von benutzerdefinierten Build-Skripten im Vergleich zu Ant viel schwieriger.

Obwohl Maven einige ernsthafte Verbesserungen vorgenommen hat, um die Erstellungsprozesse von Anwendungen einfacher und standardisierter zu gestalten, ist dies immer noch mit einem Preis verbunden, da es viel weniger flexibel als Ant ist. Dies führte zur Schaffung von Gradle, das das Beste aus beiden Welten kombiniert - Ants Flexibilität und Mavens Funktionen.

4. Gradle

Gradle ist ein Abhängigkeitsmanagement- und Build-Automatisierungs-Tool, das auf den Konzepten von Ant und Maven basiert.

Eines der ersten Dinge, die wir bei Gradle feststellen können, ist, dass im Gegensatz zu Ant oder Maven keine XML-Dateien verwendet werden.

Im Laufe der Zeit interessierten sich Entwickler immer mehr für eine domänenspezifische Sprache, mit der sie Probleme in einer bestimmten Domäne mithilfe einer für diese bestimmte Domäne zugeschnittenen Sprache lösen konnten.

Dies wurde von Gradle übernommen, der ein DSL verwendet, das entweder auf Groovy oder Kotlin basiert. Dies führte zu kleineren Konfigurationsdateien mit weniger Unordnung, da die Sprache speziell zur Lösung spezifischer Domänenprobleme entwickelt wurde. Die Konfigurationsdatei von Gradle heißt üblicherweise build.gradle in Groovy oder build.gradle.kts in Kotlin.

Beachten Sie, dass Kotlin eine bessere IDE-Unterstützung als Groovy für die automatische Vervollständigung und Fehlererkennung bietet.

Hier ist ein Beispiel für eine build.gradle- Datei für dasselbe einfache Java-Projekt mit der HelloWorld- Hauptklasse von zuvor:

apply plugin: 'java' repositories { mavenCentral() } jar { baseName = 'gradleExample' version = '0.0.1-SNAPSHOT' } dependencies { testImplementation 'junit:junit:4.12' }

Wir können den Code kompilieren, indem wir Folgendes ausführen:

gradle classes

At its core, Gradle intentionally provides very little functionality. Plugins add all useful features. In our example, we were using java plugin which allows us to compile Java code and other valuable features.

Gradle gave its build steps name “tasks”, as opposed to Ant's “targets” or Maven's “phases”. With Maven, we used Apache Maven Dependency Plugin, and it's a specific goal to copy dependencies to a specified directory. With Gradle, we can do the same by using tasks:

task copyDependencies(type: Copy) { from configurations.compile into 'dependencies' }

We can run this task by executing:

gradle copyDependencies

5. Conclusion

In this article, we presented Ant, Maven, and Gradle – three Java build automation tools.

Not surprisingly, Maven holds the majority of the build tool market today.

Gradle wurde jedoch aus folgenden Gründen in komplexeren Codebasen gut angenommen:

  • Viele Open-Source-Projekte wie Spring verwenden es jetzt
  • Dank seiner inkrementellen Builds ist es in den meisten Szenarien schneller als Maven
  • Es bietet erweiterte Analyse- und Debugging-Dienste

Allerdings scheint dieser Gradle eine steilere Lernkurve zu haben, besonders wenn Sie nicht mit Groovy oder Kotlin vertraut sind.

Weiter » Benutzerdefinierte Gradle-Plugins schreiben « Vorherige Einführung in Gradle