EJM Masterclass - Build Automation & Dependency Management

1. EJM Masterclass- Build Automation & Dependency Management David Fuenmayor Associate Consultant Java Technology Center & Innovations

2. Build Automation & Dependency Management Übersicht

3. Übersicht - Build Automation Build Automation beschreibt die Automatisierung einer Vielzahl von Aufgaben bei der Software-Entwicklung: • Kompilierung von Quellcode • Packaging von Binär-Code • Testing • Bereitstellung für Produktionssysteme • Erstellung von Dokumentationen und / oder Release Notes

4. Übersicht - Dependency Management Dependency Management Verwaltung von Projekt-Abhängigkeiten und binäre Repositoriesüber vorherige Deklaration in einem speziellen (pro-Projekt) Datei Automatisches Retrieval und Auflösung von transitiven Abhängigkeiten, Definitionen und Ressourcen Automatische Integration mit den öffentlich zugänglichen Artefakt-Repositories

5. Was erwartet mich in diesem Modul I. Grundlagen • BA & DM Umwelt • Warum BA & DM? II. Geschichte der BA & DM • Am Anfang gab es Make… • Bevor BA • BuildAutomation für C und Java (Makefile-Beispiele) • Alternativen und Weiterentwicklung (CMake, Autotools, Rake, etc) • Apache Ant: Make für Java!! • Build Automation mit Ant (Beispiel)

6. Was erwartet mich in diesem Modul II. Geschichte der BA & DM • Apache Ivy: Ant‘sbestfriend • Dependency Management mit Ivy (Beispiel) • Apache Maven: BA & DM zusammen • ConventionoverConfiguration • Build Automation & DependencyManagement mit Maven (Beispiel) • Gradle: Eine neue Hoffnung! • BA und DM mit Gradle (Beispiel)

7. Was erwartet mich in diesem Modul III. Unser Case-Study: Maven • Vor/Nach Maven • Maven Philosophie • Project Object Model (POM) • MavenArtifacts • Artifact & PluginRepos • MavenBuildLifecycle • MavenPlugins, Goals und Mojos

8. Was erwartet mich in diesem Modul IV. Maven Hands-on • Installieren Maven • Konfigurieren Maven • MavenArchetypes • MavenFirst-Run • Maven und Ant

9. Was erwartet mich in diesem Modul V. Maven Test Drive - CGI’s Pizza Shop • Build-Prozess mit Mavendefault-plugins • Ausführung von JUnitTests mit Maven-Surefire-plugin • Deployment in Tomcatserver mit Maven-Tomcat-plugin • Statische Code-Analyse mit Maven-Sonar plugin • System Testing mit Maven-Seleniumplugin • Dokumentation des Projektes mit Maven-Javadoc-plugin • Analyse von Abhängigkeiten mit Maven-Dependency-plugin

10. Build Automation & Dependency Management I - Grundlagen

11. BA & DM Umwelt Remote Repos Local Repo Project Folder Artifacts Artifacts DM Tools

12. Warum BA & DM? Transitive Abhängigkeiten: Friend-of-a-friend • Ein Enterprise-Projekt (mit Spring, Hibernate, etc.) endet einfach mit Hunderten von Abhängigkeiten (Jars). Es ist unmöglich alle Abhängigkeiten auswendig zu lernen!! • Man muss zwischen direkten und transitiven Abhängigkeiten unterscheiden. Andernfalls verliert man schnell den Überblick über den Build-Prozess! • Einige sind „Compile“ Abhängigkeiten, andere „Runtime“ (müssen mit der Anwendung gekoppelt werden) und andere sind „Provided“ Abhängigkeiten (sind im Server schon bereitgestellt)

13. Warum BA & DM? • Eine transitive Abhängigkeit von einer direkten Abhängigkeit kann auch eine direkte Abhängigkeit selbst sein. • Eine Abhängigkeit kann eine transitive Abhängigkeit einer anderen direkten Abhängigkeiten sein, oder andersherum. • Zyklische Abhängigkeiten? Zu kompliziert?? Niemand wagt es, eine Abhängigkeit nicht mehr zu entfernen. Classpathist ein Durcheinander!! • Will man eine direkte Abhängigkeit entfernen, müssen folgende Punkte beachtet werden:

14. Warum BA & DM?

15. Warum BA & DM? …und es gibt noch mehr: Versioning: • Widersprüchliche Versionen des gleichen JAR müssen erkannt und behoben werden, sonst wird die Reihenfolge der Classpath es bestimmen, welche Version einer Abhängigkeit gewinnt: Alle Arten von Nebenwirkungen und schwer zu findenden Bugs!! • Was passiert, wenn mehrere Maschinen (Entwicklung, Test, CI) verschiedene Versionen des gleichen JAR haben? Repositories: Wobekommt man die Jars? Google?

16. Build Automation & Dependency Management II - Geschichte

17. Geschichte Am Anfang gab es Make… • Compile-Befehl für eine einzelne Class (kleines C++ Projekt) >g++ –Ddefine_xsr –Ddefine_xxw –Dnumber_threads=3 –Dnumber_things=23 –Danother_option1 –Danother_option2 –Danother_option3 […] -fmessage-length=20 -fdiagnostics-show-location=once -fdiagnostics-show-option fno-gnu-keywords -fno-implicit-templates -fno-implicit-inline-templates -fno-implement-inlines -fms-extensions –l/usr/local/newmat-package/include-I/usr/include -I/usr/include/cpp4.1.1/include –l/usr/local/newmat-package/include […] –ltinyxml-Wall –pedantic –g –c ./test/src/test1.cpp ./test/includes/test1.h ./test/src/test2.cpp ./test/includes/test2.h -o myproject myproject.cpp myproject.h … • Compile-Befehl für eine einzelne Class (kleines Java Projekt) >javac–g -Xswitchcheck-sourcepath /usr/local/newmat-package/src-classpath /usr/local/foo/lib/Banners.jar -encoding ITF-8 /usr/local/newmat-package/src/farewells/GoodBye.java -d classes… […] […]

18. Geschichte Shell scripts mit mehreren solchen Befehlen sind schwer zu warten. Man muss den ganzen Dependencies-Tree neu kompilieren, immer wenn eine einzelne Zeile geändertwurde. Es sieht ein bisschen unpraktisch aus! Dasselbe hat Stuart Feldman in 1977 beiBell Labs gedacht. Das Ergebnis: Make

19. Geschichte - Make UNIX-basiertes Build Automation Tool, das eine Datei (mit dem Namen "Makefile") liest. Ein Makefile ist eine Reihe von Zielen und Abhängigkeiten (Targets & Dependencies), die "gemacht" werden sollen, immer wenn ein Target nicht mehr aktuell ist. Um ein Target zu erstellen, müssen in der Regel werden verschiedene Shell-Befehle abgerufen werden. Solche Befehle können entweder den Quellcode kompilieren oder Objekt-Code verbinden (link) oder Quellcode-Checkout aus dem Versionsverwaltung-System oder Packagingvon Dateien.

20. Geschichte - Make Makeverfügt über eine leistungsfähige Domain Specific Language (DSL):

21. Geschichte - Make Makefiles zu schreiben ist langweilig! Es gibt verschiedene Tools zur automatischen Generierung von Makefiles: CMake, NMake, GNU Autotools, u.a ...oder sogar Make „Erben“ in anderen (modernen) Sprachen. Empfohlen: Rake (Ruby DSL) http://rake.rubyforge.org/

22. Geschichte - Ant Apache Ant: Make für Java!! • Geboren als ein Apache Projekt mit dem Ziel Make zur Java-Welt zu bringen (~ Jahr 2000) • Ant hat ein ähnliches Konzept wie Makein Bezug auf die Targets und Dependencies. Bei Ant müssen T&D nicht standardmäßig Dateien sein. • Anstatt davon auszugehen, dass Shell-Befehle verfügbar sind, verwendet Antbuilt-in Befehle, um Targets zu implementieren. Damit kann Antauf jeder Java-gestützte Plattform laufen: WORA

23. Geschichte - Ant Ant verfügt über eine XML-basierte Syntax für die Erstellung der Build-Dateien anstelle eines DSL wie Make:

24. Geschichte - Ivy Apache Ivy: Ant‘s best friend (~ Jahr 2004) • Im Gegensatz zu Ant (Build Automation) ist Ivy ein Dependency-Management-Tool • Ivy verwendet Repositories, in denen die aktuellen Abhängigkeiten (Jar-Dateien) zusammen mit ihren Deskriptor-Dateien platziert werden und bietet eine Auflösung für widersprüchliche Jar Versionen • Ivy ist weit verbreitet und wird in Projekten als Standard Ergänzung von Ant eingesetzt

25. Geschichte - Ivy Ivy bietet auch XML-Dateien, die Informationen über die Abhängigkeiten von einer bestimmten Jar-Datei enthalten:

26. Geschichte - Ivy Dementsprechend mit Repositories:

27. Geschichte - Maven Apache Maven: BA & DM zusammen (~ Jahr2004) • A Project Object Model (POM-Datei) bietet die gesamte Konfiguration für ein einzelnes Projekt. • Allgemeine Konfiguration umfasst den Namen des Projekts, dessen Besitzer und seine Abhängigkeiten zu anderen Projekten. • Man kann auch einzelne Phasen des Build-Prozesses konfigurieren, die als Plugins implementiert werden

28. Geschichte - Maven Convention over Configuration Default Build-Lifecycle 1. process-resources 2. compile 3. process-test-resources 4. test-compile 5. test 6. package 7. install 8. deploy Default Projekt-Struktur

29. Geschichte - Maven XML-Konfiguration: POM Datei

30. Geschichte - Maven

31. Geschichte - Gradle Gradle: Eine neue Hoffnung (~ Jahr 2008) • Auf den Konzepten von Ant und Mavenbasiert • Keine XML-Konfiguration, sondern eine Groovy-basierte Domain Specific Language (DSL) • Gradle verwendet ein DirectedAcyclic Graph (DAG) um die Build-Reihenfolge zu bestimmen. Empfolender Link: LearnGradle: http://www.gradle.org/learn

32. Geschichte - Gradle

33. Build Automation & Dependency Management III - Maven

34. VorMaven Im Jahr 2001 gab es einen völlig anderen Ansatz für Build-Prozesse: In jedem einzelnen Projekt gab es eine verantwortliche Person, die für die Verwaltung eines maßgeschneiderten Build-Systems zuständig war Entwickler mussten Zeit von der Software-Entwicklung abziehen, um die Eigenheiten jedes neuen Projekt-Build-Systems zu lernen Um ein neues Quellcode-Analyse-Tool oder ein neues Unit-Testing Framework hinzuzufügen, musste jeder Entwickler überprüfen, ob das Tool in der maßgeschneiderten Build-Umgebung passt

35. Nach Maven Projekte haben viele gemeinsame Phasen: Build, Testen, Packaging, Dokumentation, Deployment, u.a Die Einführung eines neuen Quellcode-Analyse-Tools oder eines neuen Unit-Testing Framework erfolgt jetzt nur durch Hinzufügen eines Plugins. Aktualisierung von Versionen erfolgt nur durch Änderung einer Datei(POM) Die gleiche Idee gilt auch für Tests, Dokumentation, Erzeugen von Metriken und Berichten, Testing und Deployment. Entwickler können sich frei zwischen Projekten bewegen!!

36. Maven Philosophie Mavenliefert einen allgemeinen Ansatz für Projektmanagement. Maven gibt eine klare Richtung in der Nutzung von Best-Practices vor Maven ist mehr als nur Scripting und mehr als nur die Zentralisierung von Konfiguration in einer Datei (POM) Maven ist die Förderung einer Reihe von Standards, eine gemeinsame Schnittstelle, ein gemeinsames Life-Cycle, ein Standard-Repository-Format, ein Standard-Verzeichnis-Layout, etc. Maven ist mehr als das Tool selbst! Mavenbezieht sich auf die Konstellation von Software, Systemen und Standards, die es unterstützen

37. Maven Philosophie Die KernaspekteMavens sind: Deklarative Build-Prozesse Dependency Management Repository Management Wiederverwendung und Erweiterungdurch Plugins. Wichtige Info-Quellen: http://maven.apache.org/guides/ Empfohlen: MavenbyExample http://www.sonatype.com/books/mvnex-book/pdf/mvnex-pdf.pdf

38. Project Object Model (POM) Das POM ist eine XML-Darstellung eines Maven-Projekts in einer Datei namens pom.xml. Das POM enthält alles, was Mavenüber das Projekt wissen muss: • Verweise auf Konfigurationsdateien • Entwickler und die Rollen, die sie spielen • Das Issue-Tracking-System • Die Organisation und Lizenzen • URL, wo das Projekt zur Verfügung steht • Project Abhängigkeiten • Verwendete Plugins • ... und all die anderen kleinen Stücke, die man benötigt um das Projekt zu erstellen

39. Maven Artifacts Ein Artifact ist eine Ressource, die im Rahmen eines Maven-Builderzeugt oder verbraucht worden ist. Ein Artifact ist üblicherweise ein JAR oder ein WAR. Artifacts in Mavenwerden von einem Koordinatensystem bestehend aus groupId, artifactId und versionidentifiziert. Diese Koordinaten werden verwendet, um Abhängigkeiten (in der Regel andere JAR-Dateien) für Build und die Ausführung des Codes zu identifizieren.

40. Artifact & Plugin Repos Plugins sind besondere Artifacts, die Maven-Funktionalitäten erweitern. Plugins sind auch als JAR-Datei verfügbar. Plugins sind keine Abhängigkeit des Projekts und deshalb nicht damit geliefert. Artifacts wohnen in Repositories (local/remote) Lokale-Repos • Instanzen auf dem eigenen Computer • Cache von einem Remote-Repository • Enthält auch die temporären, noch nicht freigegeben Artefakte

41. Artifact & Plugin Repos Remote-Repos • Jede andere Art von Repository • Sie werden durch eine Vielzahl von Protokollen wie z.B. file:// und http:// abgerufen Repos aus einem File-Server oder einem HTTP-Server in einem Unternehmen, werden häufig für Releases benutzt, oder um private Artefakte zwischen Entwicklungsteams zu teilen Normalerweise kümmern wir uns um unseres lokal Reponicht. Mavenkümmert sich!

42. Artifact & Plugin Repos Maven kommuniziert mit den Remote-Repos, sowohl zum Down- als auch zum Upload von Artefakten (wenn wir die Berechtigung dazu haben) Das Herunterladen von Artefakten wird von Mavenausgelöst, immer wenn es eine Deklaration einer Abhängigkeit gibt, die nicht in dem lokalen Repo vorhanden ist Mehr Infos über Repos: http://maven.apache.org/guides/introduction/introduction-to-repositories.html

43. MavenRepos Umwelt Remote Repos Spring MavenRepo http://maven.springframework.org/release Maven Central Repo http://repo.maven.apache.org MyCompanyRepo http://repo.mycompany.com Project POM File reads updates projectPath/pom.xml Maven Plugins Artifacts Project jars copies Project Dependencies Local Repo ~/.m2/repository

44. Dependency Scopes Wir können die Transitivität der Abhängigkeiten durch Dependency-Scopes begrenzen. Es gibt 6 Scopes verfügbar: Compile: Default scope Provided: Ähnlich wie Compile. JDK/Container für runtime Runtime: Nur für Ausführung und Testing erforderlich Test: Nur für Testing erforderlich System: Ähnlich wie Provided. Man fügt die Abhängigkeit (JAR) ausdrücklich hinzu Import: Die angegebene POM sollte mit den Abhängigkeiten dieser POM ersetzt werden Wir können zusätzlich eine Abhängigkeit als „Optional“ (nicht transitive) bezeichnen.

45. Dependency Scopes Für eine Abhängigkeit mit einem bestimmten Scope(in der linken Spalte), dann werden sich ihre transitiven Abhängigkeiten (in der oberen Reihe) in einer Abhängigkeit (am Schnittpunkt) verwandeln Mehr Infos: http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html

46. Maven Build Lifecycle In Maven, wird der Prozess für den Build und die Verteilung eines bestimmten Artefaktes (Projekt) klar definiert: Der BuildLifecycle Es gibt drei built-in Build-Lifecycles: Default, Clean und Site Clean-Lifecycleübernimmt die Projekt Sanierung Default-Lifecycleübernimmt das Projekt Deployment Site-Lifecycleübernimmt die Erstellung der Dokumentation des Projekts Jeder Build-Lifecyclebesteht aus Phasen Jede Build-Phase besteht aus Goals

47. Maven Build Lifecycle Build-Lifecycle: Defaut-Lifecycle: Mehr Infos: http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html

48. MavenPlugins, Goals und Mojos Plugins sind Artefakte, die Maven Goals bereitstellen Ein Pluginbietet ein oder mehrere Goals, wobei jedes Goal eine Fähigkeit dieses Plugin darstellt (z.B. bietet der Compiler Pluginzwei Goals: compile und testCompile) Plugins können Informationen enthalten, die die Phasen des Build-Lifecycles bezeichnen, in welche jedes Goal einzubinden ist Ein Mojo ist nur eine Java-Klasse (Der Name kommt von POJO: wobei das M für Maven steht)

49. MavenPlugins, Goals und Mojos Ein Mojo stellt ein Maven Goal dar. Plugins sind JARs bestehend aus einer beliebigen Anzahl von Mojos (Goals) Ein Mojoenthält als Metadata: den Name des Goals, die Phase des Lifecycles und die Parameter, die es erwartet. • Build-Phase N • Goal • Goal • Goal • Plugin 1 • Mojo • Mojo • Mojo • Plugin 2 • Mojo • Mojo • Build-Phase M • Goal • Goal • Goal

50. Build Automation & Dependency Management IV – Hands on Maven