{"id":2571,"date":"2023-01-04T19:06:38","date_gmt":"2023-01-04T18:06:38","guid":{"rendered":"https:\/\/informatik.htwk-leipzig.de\/seminar\/?p=2571"},"modified":"2023-01-18T20:30:04","modified_gmt":"2023-01-18T19:30:04","slug":"maven","status":"publish","type":"post","link":"https:\/\/informatik.htwk-leipzig.de\/seminar\/lehrveranstaltungen\/betriebliche-informationssysteme\/2023\/maven\/","title":{"rendered":"Maven"},"content":{"rendered":"<ol>\n<li>Motivation<\/li>\n<li>Begriffserkl\u00e4rung\n<ol>\n<li>Maven<\/li>\n<li>Plugins und Goals<\/li>\n<li>Lifecycles<\/li>\n<\/ol>\n<\/li>\n<li>Zusammenhang der Komponenten<\/li>\n<li>POM<\/li>\n<li>Einrichtung im Projekt<\/li>\n<li>Gradle vs. Maven<\/li>\n<\/ol>\n<h1>1. Motivation<\/h1>\n<p>Die Funktionalit\u00e4t des Maven-Build-Systems ist breiter als der Quellcode-Compiler. Wenn eine Anwendung ausgef\u00fchrt wird, ruft Apache Maven den Compiler auf und verwaltet automatisch Abh\u00e4ngigkeiten und Ressourcen, zum Beispiel:<\/p>\n<ul>\n<li>l\u00e4dt die entsprechenden Paketversionen herunter;<\/li>\n<li>platziert Bilder, Audio- und Videodateien in den richtigen Ordnern;<\/li>\n<li>l\u00e4dt Bibliotheken von Drittanbietern.<\/li>\n<\/ul>\n<p>Das automatische Erstellen einer Anwendung ist besonders wichtig w\u00e4hrend der Entwicklungs-, Debugging- und Testphasen &#8211; Maven hilft dabei, Code und Ressourcen ohne IDE (Entwicklungsumgebung) in eine ausf\u00fchrbare Anwendung zu integrieren. Gleichzeitig ist das Montagesystem flexibel:<\/p>\n<ul>\n<li>kann in IDE verwendet werden &#8211; Eclipse, IntelliJ IDEA, NetBeans und andere;<\/li>\n<li>unabh\u00e4ngig vom Betriebssystem;<\/li>\n<li>erfordert keine Installation &#8211; das Archiv mit dem Programm kann in ein beliebiges Verzeichnis entpackt werden;<\/li>\n<li>alle notwendigen Parameter sind optimal voreingestellt;<\/li>\n<li>vereinfacht die Organisation von Teamarbeit und Dokumentation;<\/li>\n<li>startet Bibliotheken f\u00fcr Unit-Tests;<\/li>\n<li>stellt die Einhaltung von Standards sicher;<\/li>\n<li>hat eine gro\u00dfe Anzahl von Plugins und Erweiterungen.<\/li>\n<\/ul>\n<h1>2. Begriffserkl\u00e4rung<\/h1>\n<h2>2.1. Maven<\/h2>\n<p>Maven ist ein Build-Tool f\u00fcr die Projektverwaltung, mit dem sich Java-Projekte automatisieren lassen.<\/p>\n<p>Der gesamte Prozess, aus dem Quellcode eine funktionierende App zu machen, wird als Software-Build bezeichnet.<\/p>\n<h2>2.2. Plugins und Goals<\/h2>\n<p><strong>Plugins<\/strong> sind ein Satz von Zielen (goals). \u00dcblicherweise lassen sich Plugins sehr flexibel konfigurieren. Alle offiziellen Plugins von Maven-Entwicklern sind auf der offiziellen Maven-Website sehr gut dokumentiert. Beispielsweise k\u00f6nnen Sie f\u00fcr das maven-compiler-plugin auf der Apache Maven Project-Seite eine Liste aller Variablen sehen, die das Plugin steuern. Informationen zum Plugin sind unter dem <a href=\"https:\/\/maven.apache.org\/plugins\/maven-compiler-plugin\/compile-mojo.html\">Link<\/a> verf\u00fcgbar.<br \/>\n<strong>Goal<\/strong> ist eine spezielle Aufgabe, die sich auf das Erstellen und Verwalten eines Projekts bezieht. Die Hauptziele stimmen mit den Hauptphasen \u00fcberein:<\/p>\n<ul>\n<li><strong>validate;<\/strong><\/li>\n<li><strong>compile;<\/strong><\/li>\n<li><strong>test;<\/strong><\/li>\n<li><strong>package;<\/strong><\/li>\n<li><strong>verify;<\/strong><\/li>\n<li><strong>install;<\/strong><\/li>\n<li><strong>deploy;<\/strong><\/li>\n<\/ul>\n<p>Wie bereits erw\u00e4hnt, sind Plugins eine Reihe von Zielen. Beispielsweise enth\u00e4lt das Plug-in \u201emaven-compiler-plugin\u201c zwei Ziele: \u201ecompiler:compile\u201c zum Kompilieren des Hauptquellcodes des Projekts und \u201ecompiler:testCompile\u201c zum Kompilieren von Tests.<\/p>\n<h2>2.3. Lifecycles<\/h2>\n<p>Es gibt drei Build-Lebenszyklen: default, clean und site. Der Standardlebenszyklus behandelt Ihre Projektbereitstellung, der Clean-Lebenszyklus die Projektbereinigung und der Site-Lebenszyklus erstellt die Website Ihres Projekts.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter\" src=\"https:\/\/www.oreilly.com\/api\/v2\/epubs\/9781783986767\/files\/graphics\/B02157_05_01.jpg\" alt=\"Build Lifecycles\" width=\"474\" height=\"296\" \/><\/p>\n<p style=\"text-align: center\">Abbildung 1. Build Lebenszyklus [1]<\/p>\n<p>Der Lebenszyklus besteht aus Phasen. Phasen k\u00f6nnen auch null oder mehr Ziele enthalten (Abb. 1). Wenn an eine Phase keine Ziele gebunden sind, wird diese Phase nicht ausgef\u00fchrt. Aber wenn es ein oder mehrere Ziele daran gebunden hat, wird es alle diese Ziele ordnungsgem\u00e4\u00df ausf\u00fchren [2].<\/p>\n<h1>3. Zusammenhang der einzelnen Komponenten<\/h1>\n<p>Lifecycles beziehen sich auf den Lebenszyklus eines Projekts, von der Entwicklung bis zur Bereitstellung. Maven hat mehrere vordefinierte Lifecycles, wie zum Beispiel den &#8222;clean&#8220; Lifecycle, der f\u00fcr das Reinigen des Projekts verwendet wird, und den &#8222;default&#8220; Lifecycle, der f\u00fcr die Erstellung und Bereitstellung des Projekts verwendet wird.<\/p>\n<p>Phases sind Teile eines Lifecycles, die bestimmte Aktionen ausf\u00fchren. Zum Beispiel ist die &#8222;compile&#8220; Phase Teil des &#8222;default&#8220; Lifecycles und sorgt daf\u00fcr, dass die Quelldateien des Projekts kompiliert werden. Jede Phase kann mehrere (oder keine) Goals enthalten, die spezifische Aufgaben ausf\u00fchren.<\/p>\n<p>Plugins sind Erweiterungen, die Maven erm\u00f6glichen, bestimmte Aktionen auszuf\u00fchren. Jedes Plugin hat ein oder mehrere Goals, die von Maven aufgerufen werden k\u00f6nnen, um bestimmte Aktionen auszuf\u00fchren. Zum Beispiel kann das &#8222;maven-compiler-plugin&#8220; verwendet werden, um die Quelldateien des Projekts zu kompilieren, und das &#8222;maven-surefire-plugin&#8220; kann verwendet werden, um die Unit-Tests des Projekts auszuf\u00fchren.<\/p>\n<p>In Maven werden Lifecycles, Phases und Plugins zusammengef\u00fchrt, um ein Projekt von der Entwicklung bis zur Bereitstellung zu automatisieren. Wenn beispielsweise der Befehl &#8222;mvn package&#8220; ausgef\u00fchrt wird, wird Maven den &#8222;default&#8220; Lifecycle ausf\u00fchren, der mehrere Phases enth\u00e4lt, wie zum Beispiel die &#8222;compile&#8220; Phase und die &#8222;test&#8220; Phase. Jede Phase kann mehrere Goals enthalten, die von verschiedenen Plugins ausgef\u00fchrt werden.<\/p>\n<figure id=\"attachment_2626\" aria-describedby=\"caption-attachment-2626\" style=\"width: 1865px\" class=\"wp-caption alignnone\"><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-2626 size-full\" src=\"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-content\/uploads\/2023\/01\/Unbenanntes-Diagramm.drawio1.png\" alt=\"BPMN Default Lifecycle\" width=\"1865\" height=\"473\" \/><figcaption id=\"caption-attachment-2626\" class=\"wp-caption-text\">BPMN Default Lifecycle<\/figcaption><\/figure>\n<h1>4. POM<\/h1>\n<p>In Apache Maven werden POM-Dateien (Project Object Model) genutzt, um Projekt- und Konfigurationsinformationen einheitlich in XML-Struktur zu speichern. POM-Dateien bieten strukturiertes Bibliotheksmanagement und haben hierarchische Struktur in Softwareprojekten, wodurch Projektinformationen, wie die Version einer eingebundenen Bibliothek nur innerhalb oberer POMs definiert wird und in tiefer gelegenen POMs nur referenziert werden muss. Innerhalb einer POM werden Informationen \u00fcber die Datei- und Modulstruktur, eine Liste von eingebundenen projektinternen und externen Abh\u00e4ngigkeiten, Konfigurationseinstellungen mit denen verschiedene Maven Lifecycles und Plugins beschrieben werden oder auch die Repositories aus denen Abh\u00e4ngigkeiten bezogen werden, abgelegt.<\/p>\n<h3>Maven Coordinates<\/h3>\n<p>Jede POM-Datei enth\u00e4lt die Elemente groupId, artifactId und version, unter welchen die jeweilige POM in verschiedenen Repositories aufzufinden ist. Diese Attribute wirken dabei als Adresse und Zeitstempel einer Bibliotheksversion und werden auch als <em>Maven Coordinates<\/em> bezeichnet. Eine minimale POM beschreibt nur die eigene Gruppen- und Artefakt-ID mit einer gew\u00e4hlten Version, ohne Konfigurationseinstellungen oder andere Abh\u00e4ngigkeiten zu nutzen.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-2686 aligncenter\" src=\"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-content\/uploads\/2023\/01\/carbon-1.png\" alt=\"\" width=\"450\" height=\"189\" \/><\/p>\n<p style=\"text-align: center\">Abbildung 2 &#8211; Minimale POM [3]<\/p>\n<h3>Dependencies<\/h3>\n<p>Eine Hauptfunktion der POM ist die Verwaltung von projekt-internen und externen Abh\u00e4ngigkeiten. Hierf\u00fcr werden in der POM unter dem Element <em>&lt;dependencies&gt;<\/em> verschiedene Abh\u00e4ngigkeitsnamen und -versionen definiert, mit denen Bibliotheksversionen aus \u00f6ffentlichen Repositories geladen und lokal in einem .m2 Datenlager abgespeichert werden. F\u00fcr die Nutzung von lizensierten Bibliotheken, sowie die Einbindung aller Abh\u00e4ngigkeiten, welche in keinen \u00f6ffentlichen Datenlagern gefunden werden k\u00f6nnen, m\u00fcssen Bibliotheksartefakte manuell in das .m2 Datenlager eingef\u00fcgt werden. Dabei k\u00f6nnen nur Maven Artefakte einbezogen werden, ohne M\u00f6glichkeit der Nutzung von anderen Artefakttypen. Hierbei werden nicht nur explizit eingebundene Bibliotheken, sondern auch transitive Abh\u00e4ngigkeiten, welche von eingebundenen Bibliotheken genutzt werden, bezogen. Um mehrere Versionen derselben Bibliothek zu vermeiden, k\u00f6nnen Abh\u00e4ngigkeiten transitiv unter dem Element <em>&lt;exlusions&gt;<\/em> ausgeschlossen werden.<\/p>\n<p>Alle Abh\u00e4ngigkeiten, welche in einer POM eingebunden werden, werden in der Abh\u00e4ngigkeitsliste der POM definiert. Zu jeder eingebundenen Bibliotheksversion m\u00fcssen zumindest die Maven Coordinates groupId, artifactId und version angegeben werden. Folgende Informationen k\u00f6nnen zu jeder Abh\u00e4ngigkeit angegeben werden:<\/p>\n<ul>\n<li><b>groupId<\/b>,\u00a0<b>artifactId<\/b>,\u00a0<b>version<\/b>: Maven Coordinates, \u00fcber welche Bibliotheksversionen eingebunden werden<\/li>\n<li><b>classifier:<\/b> beschreibende Namenszus\u00e4tze, durch die mehrere Artefakte aus einer einzelnen POM erstellt und eingebunden werden k\u00f6nnen, um beispielsweise unterschiedliche Artefakte f\u00fcr verschiedene Systeme, Umgebungen oder auch f\u00fcr API-Dokumentationen zu beziehen<\/li>\n<li><b>type: <\/b>einzubindender Abh\u00e4ngigkeitstyp, zur Nutzung von JAR-Artefakten (Java Archive), Test-JARs f\u00fcr Testdateien, weiteren POMs oder JavaDoc Dokumenten<\/li>\n<li><b>scope:\u00a0<\/b>beschr\u00e4nkte Sichtbarkeit der eingebundenen Abh\u00e4ngigkeit<\/li>\n<li><b>systemPath: <\/b>absoluter Systempfad, \u00fcber den das Artefakt bezogen wird, wenn scope auf <em>system<\/em> gesetzt ist<\/li>\n<li><b>optional: <\/b>Abh\u00e4ngigkeiten, welche nicht transitiv eingebunden werden, sollte die POM von anderen Modulen oder Projekten eingebunden werden<\/li>\n<\/ul>\n<h3>Inheritance<\/h3>\n<p>POM-Dateien erben Informationen und Abh\u00e4ngigkeiten aus hierarchisch \u00fcbergeordneten POMs. Dies ist n\u00fctzlich, damit beispielsweise Bibliotheksversionen, Lizenzinformationen, genutzte Plugins oder Build-Einstellungen nicht innerhalb jeder POM neu definiert werden m\u00fcssen. Dabei ist es wichtig, dass \u00fcbergeordnete POMs mit dem Attribut packaging, sowie dem Wert pom gekennzeichnet werden. Hier ist zu beachten, dass die Artefakt ID einer POM nicht vererbt wird und damit in jeder POM zugewiesen werden muss. \u00dcbergeordnete POMs werden mit dem Element <em>&lt;parent&gt;\u00a0<\/em>gekennzeichnet, wobei alle POMs von einer vordefinierten Super POM mit vielen Standardkonfigurationen erben, ohne diese selbst angeben zu m\u00fcssen.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-2689 aligncenter\" src=\"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-content\/uploads\/2023\/01\/carbon.png\" alt=\"\" width=\"372\" height=\"242\" \/><\/p>\n<p style=\"text-align: center\">Abbildung 3 &#8211; Vererbung mit Parent POM [3]<\/p>\n<h3>Aggregation<\/h3>\n<p>Bei der Aggregation k\u00f6nnen \u00e4hnlich zur Vererbung Maven Kommandos innerhalb einer POM definiert werden, welche dann f\u00fcr verschiedene Module, welche in der Aggregator-POM eingebunden werden, ebenfalls ausgef\u00fchrt werden. Somit entsteht bei diesem Prinzip ein Multi-Modul, \u00fcber welches Kommandos in Sub-Modulen selbstst\u00e4ndig ausgef\u00fchrt werden. Dabei ist die Reihenfolge von benannten Sub-Modulen, sowie deren transitive Einbindungen unwichtig.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-2731 aligncenter\" style=\"text-align: center\" src=\"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-content\/uploads\/2023\/01\/carbon-2.png\" alt=\"\" width=\"395\" height=\"244\" \/><\/p>\n<p style=\"text-align: center\">Abbildung 4 &#8211; Aggregation mit Sub-Modulen [4]<\/p>\n<h1>5. Einrichtung im Projekt<\/h1>\n<p>Maven braucht keine umst\u00e4ndlichen Installer und Einrichtungskonfigurationen, damit es genutzt werden kann. Es reicht, wenn Maven Befehle \u00fcber die Kommandozeile ausf\u00fchrbar sind, indem der Pfad zum Maven Home Directory als Systemumgebungsvariable gesetzt ist.<\/p>\n<h3>Maven Wrapper<\/h3>\n<p>Es kann w\u00fcnschenswert sein keine bestimmte Maven Version auf einem System zur Ausf\u00fchrung eines Projektes installieren zu m\u00fcssen. F\u00fcr diesen Fall kann Maven-Wrapper genutzt werden, welches keine systemweite Einrichtung von Maven voraussetzt. Es muss lediglich die Maven Wrapper Distribution gedownloadet und in der Umgebung des Projektes, welches Maven nutzen soll, mit dem Maven-Goal <em>wrapper:wrapper<\/em> ausgef\u00fchrt werden.[5 ] Bei diesem Befehl kann ebenfalls eine ausgew\u00e4hlte Maven Version angegeben werden, welche anschlie\u00dfend wie eine eingebundene Bibliothek im .m2 Datenlager abgelegt wird. Nach Ausf\u00fchrung k\u00f6nnen typische Maven Befehle wie <code class=\"language-bash\"><span class=\"pln\">mvn clean install<\/span><\/code> stattdessen durch <code class=\"language-bash\"><span class=\"pun\">.\/<\/span><span class=\"pln\">mvnw clean install<\/span><\/code> oder <code class=\"language-bash\"><span class=\"pln\">mvnw<\/span><span class=\"pun\">.<\/span><span class=\"pln\">cmd clean install<\/span><\/code> (Windows) ausgef\u00fchrt werden.<\/p>\n<h3>Getting Started<\/h3>\n<p>Falls Maven f\u00fcr ein Projekt genutzt werden soll, kann das Maven-Goal <em>mvn archetype:generate<\/em> genutzt, um die typische Maven Modulstruktur mir POM-Dateien zu initialisieren. [6] Anschlie\u00dfend k\u00f6nnen alle Maven Befehle, welche zur Entwicklung des Projektes beitragen genutzt werden, wie <em>mvn compile<\/em>, zur Kompilierung von Quellcode, <em>mvn test<\/em> zum Ausf\u00fchren von Testklassen oder <em>mvn clean<\/em> zum Aufr\u00e4umen von target Ordnern. Typische Maven Ausgaben sollten nun auch auf der Kommandozeile zu sehen sein.<\/p>\n<h1>6. Gradle vs. Maven<\/h1>\n<p>Gradle ist ein Build-Automation-Tool, das als Konkurrent zu Maven in der Java-Entwicklung gilt. Dabei unterst\u00fctzt Gradle auch andere Sprachen wie C++, Python und Kotlin.<\/p>\n<p>Gradle legt den Fokus besonders auf Performance, Benutzerfreundlichkeit, Wartbarkeit und Flexibilit\u00e4t und verwendet dabei &#8222;Tasks&#8220; als Arbeitsunits, die den &#8222;Goals&#8220; in Maven entsprechen. Dies erm\u00f6glicht es Gradle, noch mehr Flexibilit\u00e4t und Steuerung in Bezug auf die Art und Weise, wie Build-Prozesse ausgef\u00fchrt werden, zu bieten.<\/p>\n<p>Damit bietet Gradle eine leistungsstarke Alternative zu Maven und ist vielseitig genug, um in einer Vielzahl von Projekten eingesetzt zu werden. Es ist besonders f\u00fcr Benutzer geeignet, die mehr Flexibilit\u00e4t und Kontrolle in Bezug auf den Build-Prozess w\u00fcnschen.<\/p>\n<p>Im Folgenden werden einige Kategorien n\u00e4her betrachtet, die zur Gegen\u00fcberstellung der beiden Tools dienen.<\/p>\n<h3><strong>Beliebtheit &amp; Bekanntheit<\/strong><\/h3>\n<p>Maven ist das momentan beliebteste Build-Automation-Tool f\u00fcr Java auf dem Markt und ist auch im industriellen Bereich weiter verbreitet als Gradle. Die Beliebtheit kann ein wichtiger Faktor bei der Entscheidung zwischen verschiedenen Build-Automation-Tools sein, da mit einem weit verbreiteteren Tool oft einfacher zu arbeiten ist, da mehr Dokumentation, Erfahrungswerte und Expertenwissen zur Verf\u00fcgung stehen. Gradle ist dabei im Vergleich zu Maven ein \u201eNewcomer\u201c. Die Anzahl der Entwickler, die gut mit Gradle vertraut sind, ist folglich begrenzt. Aufgrund der h\u00f6heren Bekanntheit gibt es auch mehr Plugins f\u00fcr Maven als f\u00fcr Gradle.<\/p>\n<h3><strong>Build-Skripts<\/strong><\/h3>\n<p>Maven beschreibt Projektbuilds in der ausf\u00fchrlichen Markup-Sprache XML, w\u00e4hrend Gradle eine Domain-spezifische Sprache (DSL) verwendet, die auf den Programmiersprachen Groovy oder Kotlin basiert. Die Verwendung von tag-basiertem XML in Maven macht die Skripte im Vergleich zu code-basierten DSLs wie Gradle schwerer lesbar und verst\u00e4ndlich, insbesondere bei gr\u00f6\u00dferen Projekten. F\u00fcr viele Benutzer ist das build.gradle von Gradle einfacher zu lesen und zu pflegen als die pom.xml von Maven. Allerdings hat Gradle auch eine umfangreiche Dokumentation, was es erforderlich macht, sich vorheriges Wissen \u00fcber bestimmte Begriffe anzueignen, um die Build-Skripte vollst\u00e4ndig zu verstehen.<\/p>\n<h3><strong>Performance<\/strong><\/h3>\n<p>Gradle ist im Vergleich zu Maven in verschiedenen Build-Situationen deutlich schneller, in einigen F\u00e4llen sogar bis zu 85x schneller. Ein herausstechendes Performance-Features von Gradle sind inkrementelle Builds. Dadurch k\u00f6nnen unn\u00f6tige Ausf\u00fchrungen von Tasks oder Testl\u00e4ufen verhindert werden. Gradle f\u00fchrt somit nur Tasks aus, wenn sie im vorherigen Build noch nicht ausgef\u00fchrt wurden und sich deren Input oder Output ver\u00e4ndert hat. Auf diese Weise werden Full-Rebuilds bei kleinen Code\u00e4nderungen vermieden. Ein weiteres Feature ist die inkrementelle Kompilierung, die das gleiche Konzept wie inkrementelle Builds bei Code\u00e4nderungen verfolgt. Schlie\u00dflich gibt es den Gradle Daemon, der Gradle im Hintergrund kontinuierlich ausf\u00fchrt und bereith\u00e4lt, um einen Build auszuf\u00fchren, sobald er angefordert wird.<\/p>\n<h3><strong>Anpassungsm\u00f6glichkeiten<\/strong><\/h3>\n<p>Gradle bietet viele M\u00f6glichkeiten, um die Buildlogik anzupassen und wiederzuverwenden. Dazu geh\u00f6rt das Hinzuf\u00fcgen eigener Logik innerhalb des Build-Skripts, ohne ein konkretes separates Plugin entwickeln zu m\u00fcssen. So k\u00f6nnen Tasks, Methoden und Klassen definiert werden, die in anderen Teilen des Skripts wiederverwendet werden k\u00f6nnen. Zus\u00e4tzlich k\u00f6nnen Elemente in einer eigenen Datei im &#8222;buildSrc&#8220;-Ordner abgelegt werden, die in Subprojekten wiederverwendet werden k\u00f6nnen. Die Wiederverwendung von Buildlogik hilft dabei beispielweise, Duplikationen zu vermeiden, insbesondere bei gro\u00dfen Projekten. Allerdings ist dabei notwendig, vorheriges Wissen \u00fcber Gradle zu erwerben, um neue Tasks zu erstellen.<\/p>\n<p>Im Gegensatz dazu hat Maven nur eine Option, um die Buildlogik anzupassen und wiederzuverwenden: das Schreiben eines eigenen Plugins. Dies erfordert jedoch zwingend die Erstellung eines separaten Projekts und die Ver\u00f6ffentlichung des Plugin-Artefakts zur Nutzung im Projekt.<\/p>\n<h3><strong>Standardisierung<\/strong><\/h3>\n<p>Maven bietet Entwicklern eine default Ordnerstruktur f\u00fcr Javaprojekte, die ihnen unter anderem dabei hilft, leichter zwischen Projekten zu wechseln. Diese Standardisierung der Ordnerstruktur erleichtert es Entwicklern, sich schneller in neuen Projekten zurechtzufinden und beschleunigt die Einarbeitung in das Projekt. Maven standardisiert auch, wie Javaprojekte grunds\u00e4tzlich gebaut werden. Dies bedeutet, dass der Buildprozess eines Javaprojekts mithilfe von Maven in einer einheitlichen Art und Weise gesteuert wird, was wiederum die Wiederverwendbarkeit von Buildskripten erleichtert.<\/p>\n<h3><strong>Gemeinsamkeiten<\/strong><\/h3>\n<p>Maven und Gradle haben ebenfalls einige Gemeinsamkeiten in Bezug auf ihre Funktionalit\u00e4t. Beide bieten Plugins f\u00fcr verschiedene Zwecke an, wie beispielsweise die statische Code-Analyse oder das Berechnen der Testcode-Coverages. Diese Plugins erweitern die Funktionalit\u00e4t beider Tools und erleichtern es Entwicklern, bestimmte Aufgaben auszuf\u00fchren. \u00dcber Artefakt Repositories k\u00f6nnen (transitive) Abh\u00e4ngigkeiten bezogen werden. Maven nutzt dabei das Maven Central Repository, w\u00e4hrend Gradle das JCenter Repository verwendet. Es ist auch m\u00f6glich, ein eigenes privates Repository zu definieren und zu verwenden. Diese Gemeinsamkeiten erleichtern es Entwicklern, ihre Projekte aufzusetzen und zu verwalten.<\/p>\n<h3><strong>Gradle vs. Maven &#8211; Fazit<br \/>\n<\/strong><\/h3>\n<p>Zusammengefasst l\u00e4sst sich sagen, dass Gradle in Situationen verwendet werden sollte, in denen Vielseitigkeit, Geschwindigkeit und inkrementelle Builds von hoher Bedeutung sind. Dies macht es besonders gut geeignet f\u00fcr gro\u00dfe Projekte, in denen schnelle Buildzeiten und die Vermeidung von unn\u00f6tigen Ausf\u00fchrungen von Tasks wichtig sind. Maven hingegen sollte in Situationen verwendet werden, in denen Modularisierung, Dependency Management, Best\u00e4ndigkeit, Plugins und Konventionen (\u00fcber Konfiguration) priorisiert werden. Maven eignet sich daher besser f\u00fcr kleine Projekte, in denen die Einhaltung von Konventionen und das Verwalten von Abh\u00e4ngigkeiten wichtig sind. Allerdings ist Maven auch f\u00fcr gro\u00dfe Projekte geeignet, insbesondere wegen seiner umfangreichen Plugin-Sammlung und seiner konventionellen Ordnerstruktur.<\/p>\n<p>&nbsp;<\/p>\n<h3>Quellen<\/h3>\n<ol>\n<li class=\"title\">https:\/\/www.oreilly.com\/library\/view\/maven-essentials\/9781783986767\/ch05.html<\/li>\n<li>https:\/\/maven.apache.org\/guides\/introduction\/introduction-to-the-lifecycle.html<\/li>\n<li>https:\/\/maven.apache.org\/pom.html<\/li>\n<li>https:\/\/devflection.com\/posts\/2020-04-12-maven-part-3\/<\/li>\n<li>https:\/\/maven.apache.org\/wrapper\/maven-wrapper-plugin\/usage.html<\/li>\n<li>https:\/\/maven.apache.org\/guides\/getting-started\/index.html<\/li>\n<li>https:\/\/medium.com\/@yetanothersoftwareengineer\/maven-lifecycle-phases-plugins-and-goals-25d8e33fa22<\/li>\n<li>https:\/\/dzone.com\/articles\/gradle-vs-maven<\/li>\n<li>https:\/\/tomgregory.com\/maven-vs-gradle-comparison\/<\/li>\n<li>https:\/\/www.interviewbit.com\/blog\/gradle-vs-maven\/<\/li>\n<li>https:\/\/www.geeksforgeeks.org\/difference-between-gradle-and-maven\/<\/li>\n<li>https:\/\/medium.com\/@yetanothersoftwareengineer\/maven-lifecycle-phases-plugins-and-goals-25d8e33fa22<\/li>\n<li>https:\/\/cguntur.me\/2020\/05\/29\/understanding-apache-maven-part-4\/<\/li>\n<li>https:\/\/www.logicbig.com\/tutorials\/build-tools\/apache-maven\/maven-lifecycle-phases-goals.html<\/li>\n<li>https:\/\/www.appsdeveloperblog.com\/maven-goals-and-phases-tutorial\/<\/li>\n<li>https:\/\/www.baeldung.com\/maven-goals-phases<\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"<p>Motivation Begriffserkl\u00e4rung Maven Plugins und Goals Lifecycles Zusammenhang der Komponenten POM Einrichtung im Projekt Gradle vs. Maven 1. Motivation Die<\/p>\n","protected":false},"author":133,"featured_media":2645,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-2571","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-betriebliche-informationssysteme"],"_links":{"self":[{"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/posts\/2571","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/users\/133"}],"replies":[{"embeddable":true,"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/comments?post=2571"}],"version-history":[{"count":18,"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/posts\/2571\/revisions"}],"predecessor-version":[{"id":2842,"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/posts\/2571\/revisions\/2842"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/media\/2645"}],"wp:attachment":[{"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/media?parent=2571"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/categories?post=2571"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/tags?post=2571"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}