{"id":745,"date":"2015-11-08T09:00:48","date_gmt":"2015-11-08T07:00:48","guid":{"rendered":"http:\/\/invidit.de\/blog\/?p=745"},"modified":"2015-11-08T13:22:13","modified_gmt":"2015-11-08T11:22:13","slug":"konfliktmanagement-mit-maven","status":"publish","type":"post","link":"https:\/\/invidit.de\/blog\/konfliktmanagement-mit-maven\/","title":{"rendered":"Konfliktmanagement mit Maven"},"content":{"rendered":"

Hallo Spa\u00df-Coder.<\/p>\n

Nachdem wir im ersten Teil dieser Artikelreihe Maven ein wenig n\u00e4her kennenlernen durften, gehen wir nun einen Schritt weiter. Wir zeigen weitere Eigenschaften von Maven auf, die unseren Entwicklungsalltag erleichtern.<\/p>\n

In dieser Artikelreihe m\u00f6chten wir ein bisschen Licht ins Dunkel um das Mysterium von Apache Maven bringen. Fragen wie „Was ist Maven?“, „Wobei hilft mir Maven?“ oder „Wann soll ich Maven verwenden?“ werden wir beantworten. Dabei starten wir ganz am Anfang<\/a> und versuchen die Einstiegsh\u00fcrde so klein wie m\u00f6glich zu halten. Wer jetzt noch \u00e4ngstlichen Respekt<\/em> vor Maven hat, sollte die Angst nach dieser Artikelreihe abgelegt haben und nur noch anerkennenden Respekt<\/em> f\u00fcr Maven empfingen.
\nUnserer Ansicht nach ist Maven im Umfeld der Java-Programmierung ein unverzichtbar hilfreiches Werkzeug.<\/p>\n

 <\/p>\n

Raus aus der DLL… \u00e4h…JAR-H\u00f6lle!<\/h1>\n

Wer von euch schon mal an gro\u00dfen Projekten gearbeitet hat, in dem die Abh\u00e4ngigkeiten nicht mit einem Werkzeug verwaltet wurden, kennt wahrscheinlich die Situation: Es gibt eine neue Version der Software, ist aber auf Teufel komm raus nicht zum Laufen zu bringen. Warum nicht? Irgendwas fehlt! Kompilierfehler, ClassNotFoundException, FileNotFoundException, … \u00e4rgerlich! Irgendwer hat mal wieder vergessen alles r\u00fcber zu kopieren. *grummel*<\/p>\n

Und dieser Irgendwer konnte gar nicht mal so viel daf\u00fcr. Er hat selbst lange Zeit gebraucht herauszufinden, dass f\u00fcr die neue Bibliothek A die er gebraucht hat eine zweite Bibliothek B erforderlich ist. Als es dann darum ging, die Anwendung den anderen Entwicklern (oder auf der Testumgebung) zur Verf\u00fcgung zu stellen, hatte er diese zweite Bibliothek schlicht vergessen.<\/p>\n

Ich m\u00f6chte das mal anhand eines Beispiels verdeutlichen. Nehmen wir mal an, wir wollen unser TicTacToe aus dem ersten Teil der Artikelreihe um eine Highscore erweitern, die wir \u00fcber einen Rest-Service ansprechen. Was wir daf\u00fcr brauchen verr\u00e4t uns Google recht schnell: Spring-Web und Jackson-Databind. Wir k\u00f6nnen uns diese Bibliotheken nun herunterladen, an einer zentralen Stelle ablegen in unserer IDE den Classpath unserer Anwendung erweitern… oder unsere POM.xml entsprechend um diese Abh\u00e4ngigkeiten erg\u00e4nzen. Wir w\u00e4hlen nat\u00fcrlich den zweiten Weg:<\/p>\n

<groupId>de.invidit<\/groupId>\r\n<artifactId>tictactoe<\/artifactId>\r\n<version>0.0.1-SNAPSHOT<\/version>\r\n\r\n<dependencies>\r\n    <dependency>\r\n        <groupId>org.springframework<\/groupId>\r\n        <artifactId>spring-web<\/artifactId>\r\n        <version>4.2.2.RELEASE<\/version>\r\n    <\/dependency>\r\n    <dependency>\r\n        <groupId>com.fasterxml.jackson.core<\/groupId>\r\n        <artifactId>jackson-databind<\/artifactId>\r\n        <version>2.5.3<\/version>\r\n    <\/dependency>\r\n<\/dependencies><\/pre>\n
Lassen wir uns nun mal den Abh\u00e4ngigkeitsgraphen dazu anzeigen, erleben wir eine \u00dcberraschung:<\/p>\n
\"maven-transitive-dependency\"<\/a>
Erstellt mit IntelliJ IDEA UML-Plugin.<\/span><\/p><\/div>\n
Statt den erwarteten zwei Abh\u00e4ngigkeiten erhalten wir in Summe unglaubliche elf! Dabei manuell den \u00dcberblick zu behalten ist sicher nicht einfach.<\/p>\n
Durch das Prinzip der transitiven Abh\u00e4ngigkeiten<\/em> aber nimmt Maven uns diese Last von den Schultern. Jedes Artefakt kennt seine Abh\u00e4ngigkeiten, welche wieder um seine Abh\u00e4ngigkeiten kennt, usw. Dadurch wei\u00df Maven ganz genau, welche Artefakte ben\u00f6tigt werden.<\/p>\n
Das Ganze funktioniert nat\u00fcrlich nur dann, wenn jedes der Artefakte ein Maven-Modul ist und eine pom.xml besitzt, die es beschreibt. Das ist aber f\u00fcr die wichtigsten Java-Projekte im Open-Source Umfeld der Fall.<\/p>\n
 <\/p>\n
Versionskonflikte<\/h2>\n
Ein weiteres Problem sind unterschiedliche Versionen der gleichen Bibliothek. Hat ein anderer Entwickler in unserem Team etwa bereits mal einen Rest-Service konsumiert und ebenfalls Spring-Web dazu verwendet, hat er dazu ggf. eine andere Version verwendet. Da wir das nicht unbedingt wissen, f\u00fchren wir eine neue Version ein.<\/p>\n
Auch f\u00fcr dieses Problem bietet Maven eine L\u00f6sung an. \u00dcber Dependency Management <\/em>bietet Maven die M\u00f6glichkeit, die Ermittlung der Version zu zentralisieren.<\/p>\n
Als Entwickler gebe ich also nicht mehr an, welches Artefakt ich in welcher Version haben m\u00f6chte, sondern nur noch welches Artefakt ich ben\u00f6tige. Um die Version k\u00fcmmert sich dann das Dependency Management von Maven.<\/p>\n
Das obige Beispiel noch einmal mit Dependency Management:<\/p>\n
<groupId>de.invidit<\/groupId>\r\n<artifactId>invid-parent<\/artifactId>\r\n<version>1<\/version>\r\n\r\n<artifactId>tictactoe<\/artifactId>\r\n<version>0.0.1-SNAPSHOT<\/version>\r\n\r\n<dependencies>\r\n    <dependency>\r\n        <groupId>org.springframework<\/groupId>\r\n        <artifactId>spring-web<\/artifactId>\r\n    <\/dependency>\r\n    <dependency>\r\n        <groupId>com.fasterxml.jackson.core<\/groupId>\r\n        <artifactId>jackson-databind<\/artifactId>\r\n    <\/dependency>\r\n<\/dependencies><\/pre>\n
Wir geben also keine Version bei unseren Artefakten mehr an. Woher aber wird diese nun ermittelt? \u00dcber unseren Parent. Wir haben am Anfang der pom.xml einen Eintrag erg\u00e4nzt, der ein Artefakt mit dem Namen invid-parent<\/em> als unseren Parent definiert. Schauen wir doch mal in die pom.xml von invid-parent.<\/p>\n
<groupId>de.invidit<\/groupId>\r\n<artifactId>invid-parent<\/artifactId>\r\n<version>1<\/version>\r\n<packaging>pom<\/packaging>\r\n\r\n<dependencyManagement>\r\n    <dependency>\r\n        <groupId>org.springframework<\/groupId>\r\n        <artifactId>spring-web<\/artifactId>\r\n        <version>4.2.2.RELEASE<\/version>\r\n    <\/dependency>\r\n    <dependency>\r\n        <groupId>com.fasterxml.jackson.core<\/groupId>\r\n        <artifactId>jackson-databind<\/artifactId>\r\n        <version>2.5.3<\/version>\r\n    <\/dependency>\r\n<\/dependencyManagement><\/pre>\n
Hier haben wir also eine neue Sektion mit dem Tag dependencyManagement<\/em>, in dem wir f\u00fcr alle unterliegenden POMs die Versionen festlegen.<\/p>\n
Wichtig:<\/strong> Durch den Eintrag im Bereich dependencyManagement<\/em>, haben wir keine Abh\u00e4ngigkeit festgelegt. Wird dieses Artefakt nicht noch einmal als dependency<\/em> deklariert, wird Maven es niemals herunterladen und Verwenden. Eine Abh\u00e4ngigkeit im dependencyManagement<\/em> sagt also nur aus: „f\u00fcr den Fall, das wir dieses Artefakt brauchen, und keine Version angegeben ist, verwende die folgende Version.“<\/p>\n
Treten solche Konflikte \u00fcber eine transitive Abh\u00e4ngigkeit auf, bekommen wir sie damit nat\u00fcrlich nicht in den Griff. Maven hat aber eine ausgefeilte Strategie, die beste Version f\u00fcr das Projekt zu bestimmen. Bislang hat uns diese noch keine Probleme bereitet. Von der Apache-Maven Webseite<\/a>: „[…]by default Maven resolves version conflicts with a nearest-wins strategy.“<\/p>\n
 <\/p>\n
Solang du deine F\u00fc\u00dfe unter meinen Tisch stellst…<\/h1>\n
Aber was war das den da mit dem Parent? Wir geben in einem parent<\/em> ein Artefakt an und dieses sagt uns dann was zu tun ist? Genauso wie ein strenger Vater dies tut? Nicht ganz. Genau wie die dargestellte Erziehungsmethode au\u00dfer Mode ist, l\u00e4sst sich auch unser Projekt nicht vorschreiben, was es zu tun oder zu lassen hat.<\/p>\n
Maven arbeitet nach dem Prinzip Convention over Configuration<\/em> und macht sich das auch hier zunutze. Geben wir im vorgenannten Beispiel bei Spring-Web in unserer pom.xml eine andere Version an, als im dependencyManagement<\/em> des Parent angegeben ist, gilt diese. Der Vater kann hier also nur einen Rat geben; die Entscheidung tr\u00e4gt immer noch das Kind, in diesem Fall also unser Projekt.<\/p>\n
Das als parent<\/em> angegebene Artefakt muss existieren. Es muss dabei aber nicht einmal ein lauff\u00e4higes Java-Projekt sein. Wir sehen in unserem Parent folgende Angabe: <packaging>pom<\/packaging><\/code> Dies bewirkt, dass eben keine JAR-Datei herauskommt (das ist der Standardwert, wenn nichts angegeben ist, also die Convention<\/em>), sondern wie angegeben (Configuration<\/em>) eine pom.xml. Dabei sprechen wir diese mit den Maven-Koordinaten f\u00fcr ein Artefakt an, der GAV<\/strong>.<\/p>\n
Die Vererbung der Konfiguration erfolgt dabei \u00fcber beliebig viele Stufen. Jede pom.xml kann einen Parent haben, von dem die Konfigurationen verwendet werden, wenn keine abweichenden angegeben wurden.<\/p>\n
Dazu nochmal ein Beispiel. Im Standard von Maven (Convention<\/em>) ist die Kompatibilit\u00e4t mit dem Java-Compiler Version 1.3. M\u00f6chten wir nun eine andere Kompiler-Version, z.B. 1.8 verwenden, erfolgt diese \u00c4nderung explizit in der pom.xml:<\/p>\n
<plugins>\r\n    <plugin>\r\n        <artifactId>maven-compiler-plugin<\/artifactId>\r\n        <version>3.1<\/version>\r\n        <configuration>\r\n            <source>1.8<\/source>\r\n            <target>1.8<\/target>\r\n        <\/configuration>\r\n    <\/plugin>\r\n<\/plugins>\r\n<\/pre>\n
Alle darunterliegenden Module verwenden von da an die Kompiler-Version 1.8, bis wieder eine anders lautende Konfiguration vorgenommen wird. Was recht kompliziert klingt f\u00fchrt im Alltag dazu, dass ich mich in meinem aktuellen Projekt auf das Wesentliche konzentrieren kann. Alles globale wurde einmal f\u00fcr das Projekt sinnvoll festgelegt und muss von mir nun nicht erneut bedacht werden.<\/p>\n
Faustregel: Fehlt eine Angabe, schau in den Parent.<\/p>\n
 <\/p>\n
Strukturelle Integrit\u00e4t<\/h1>\n
Zum Abschluss m\u00f6chte ich noch eine Konvention vorstellen, die grundlegend ist, wenn wir neue Module anlegen, n\u00e4mlich die Verzeichnisstruktur eines Maven-Projekts. Hierin sind viele Festlegungen enthalten, die Maven verwendet um das Modul richtig zu bauen.<\/p>\n
Die Struktur unseres Projekts TicTacToe sieht folgenderma\u00dfen aus:<\/p>\n\n\n\n
\"maven-folder-structure\"<\/a><\/td>\n\n