© CGI Group Inc. CONFIDENTIAL

EJM Masterclass- Build Automation & Dependency Management

David FuenmayorAssociate ConsultantJava Technology Center & Innovations

Build Automation & Dependency Management

Übersicht

3

Übersicht - Build AutomationBuild 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

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

Übersicht - Dependency Management

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• Build Automation 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

II. Geschichte der BA & DM

• Apache Ivy: Ant‘s best friend• Dependency Management mit Ivy (Beispiel)

• Apache Maven: BA & DM zusammen• Convention over Configuration• Build Automation & Dependency Management mit Maven (Beispiel)

• Gradle: Eine neue Hoffnung!• BA und DM mit Gradle (Beispiel)

Was erwartet mich in diesem Modul

7

Was erwartet mich in diesem Modul

III. Unser Case-Study: Maven

• Vor/Nach Maven

• Maven Philosophie

• Project Object Model (POM)

• Maven Artifacts

• Artifact & Plugin Repos

• Maven Build Lifecycle

• Maven Plugins, Goals und Mojos

8

IV. Maven Hands-on

• Installieren Maven

• Konfigurieren Maven

• Maven Archetypes

• Maven First-Run

• Maven und Ant

Was erwartet mich in diesem Modul

9

Was erwartet mich in diesem Modul

V. Maven Test Drive - CGI’s Pizza Shop

• Build-Prozess mit Maven default-plugins

• Ausführung von JUnit Tests mit Maven-Surefire-plugin

• Deployment in Tomcat server mit Maven-Tomcat-plugin

• Statische Code-Analyse mit Maven-Sonar plugin

• System Testing mit Maven-Selenium plugin

• Dokumentation des Projektes mit Maven-Javadoc-plugin

• Analyse von Abhängigkeiten mit Maven-Dependency-plugin

Build Automation & Dependency Management

I - Grundlagen

11

BA & DM UmweltRemote Repos

ArtifactsArtifacts

Local RepoProject Folder

DM Tools

12

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)

Warum BA & DM?

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.Classpath ist ein Durcheinander!!

• Will man eine direkte Abhängigkeit entfernen, müssen folgende Punkte beachtet werden:

14

Warum BA & DM?

15

…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: Wo bekommt man die Jars? Google?

Warum BA & DM?

II - Geschichte

Build Automation & Dependency Management

17

GeschichteAm 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

• Shell scripts mit mehreren solchen Befehlen sind schwer zu warten.

• Man muss den ganzen Dependencies-Tree neu kompilieren, immer wenn eine einzelne Zeile geändert wurde.

Es sieht ein bisschen unpraktisch aus!

Dasselbe hat Stuart Feldman in 1977 bei Bell Labs gedacht.

Das Ergebnis: Make

Geschichte

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 Packaging von Dateien.

20

Geschichte - MakeMake verfü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 - AntApache 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 Make in 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 Ant built-in Befehle, um Targets zu implementieren. Damit kann Ant auf jeder Java-gestützte Plattform laufen: WORA

23

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

24

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

Geschichte - Ivy

25

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

26

Geschichte - IvyDementsprechend mit Repositories:

27

Geschichte - Maven

Apache Maven: BA & DM zusammen (~ Jahr 2004)

• 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-resources2. compile3. process-test-resources4. test-compile5. test6. package7. install8. deploy

Default Projekt-Struktur

29

Geschichte - MavenXML-Konfiguration: POM Datei

30

Geschichte - Maven

31

Geschichte - Gradle

Gradle: Eine neue Hoffnung (~ Jahr 2008)

• Auf den Konzepten von Ant und Maven basiert

• Keine XML-Konfiguration, sondern eine Groovy-basierte Domain Specific Language (DSL)

• Gradle verwendet ein Directed Acyclic Graph (DAG) um die Build-Reihenfolge zu bestimmen.

Empfolender Link: Learn Gradle: http://www.gradle.org/learn

32

Geschichte - Gradle

III - Maven

Build Automation & Dependency Management

34

Vor MavenIm 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• Maven liefert 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! Maven bezieht sich auf die Konstellation von Software, Systemen und Standards, die es unterstützen

37

Maven PhilosophieDie Kernaspekte Mavens sind:

• Deklarative Build-Prozesse• Dependency Management• Repository Management• Wiederverwendung und Erweiterung durch Plugins.

Wichtige Info-Quellen:http://maven.apache.org/guides/

Empfohlen: Maven by Examplehttp://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 ArtifactsEin Artifact ist eine Ressource, die im Rahmen eines Maven-Build erzeugt oder verbraucht worden ist. Ein Artifact ist üblicherweise ein JAR oder ein WAR.

Artifacts in Maven werden von einem Koordinatensystem bestehend aus groupId, artifactId und version identifiziert.

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 Repo nicht. Maven kü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 Maven ausgelö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

Maven Repos Umwelt

Remote Repos

Artifacts

Local Repo~/.m2/repository

Maven Central Repohttp://repo.maven.apache.org

MyCompany Repohttp://repo.mycompany.com

Spring Maven Repohttp://maven.springframework.org/release

Maven Plugins

Project Dependencies

Project jars

Project POM File

projectPath/pom.xml

reads

copies

updates

44

Dependency ScopesWir 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

compile provided runtime test

compile compile(*) - runtime -

provided provided - provided -

runtime runtime - runtime -

test test - test -

Mehr Infos:http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html

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

46

Maven Build LifecycleIn Maven, wird der Prozess für den Build und die Verteilung eines bestimmten Artefaktes (Projekt) klar definiert: Der Build Lifecycle

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-Lifecycle besteht aus PhasenJede Build-Phase besteht aus Goals

47

Maven Build LifecycleBuild-Lifecycle:

Phase 1

• Goal 1• Goal 2• …• Goal n

Phase 2

• Goal 1• Goal 2• …• Goal n

Phase N

• …

Defaut-Lifecycle:

Mehr Infos:http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html

48

Maven Plugins, Goals und Mojos

• Plugins sind Artefakte, die Maven Goals bereitstellen

• Ein Plugin bietet ein oder mehrere Goals, wobei jedes Goal eine Fähigkeit dieses Plugin darstellt (z.B. bietet der Compiler Plugin zwei 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

Maven Plugins, Goals und Mojos

• Ein Mojo stellt ein Maven Goal dar. Plugins sind JARs bestehend aus einer beliebigen Anzahl von Mojos (Goals)

• Ein Mojo enthält als Metadata: den Name des Goals, die Phase des Lifecycles und die Parameter, die es erwartet.

Plugin 1 Mojo Mojo Mojo

Build-Phase M Goal Goal Goal

Build-Phase N Goal Goal Goal

Plugin 2 Mojo Mojo

IV – Hands on MavenBuild Automation & Dependency Management

51

Installation

Maven kommt lightweight!Maven lädt Plugins und Abhängigkeiten (JAR) on-demand herunter

• Download: http://maven.apache.org/download.cgi • Unzip in einem beliebigen Verzeichnis (M2_HOME)

• Umfeld-Variable setzen:M2_HOME=c:\path-to-maven-dir\apache-maven-3.0.xPATH=%PATH%;%M2_HOME%\bin

• Eine Maven-Installation verfügt über zwei wichtige Verzeichnisse:• Maven Install Directory (M2_HOME)• Maven Local Repo (~ /. M2)

52

KonfigurationGlobale Maven Konfigurationsdatei: settings.xml

• Enthält was nicht mit dem pom.xml Datei ausgeliefert werden soll:

• Identität der Entwickler• Lokalen Einstellungen• Proxy-Informationen• Lokale Server-Instanzen, u.a.

• Sollte von M2_HOME in ~/.m2/settings.xml kopiert werden

Weitere Informationen:http://maven.apache.org/ref/3.0.4/maven-settings/settings.html

53

Archetypes• Archetype ist ein built-in Maven Plugin

• Archetype wird für die Erstellung von Maven Projektvorlagen (Archetypes/Templates) verwendet

• Archetype bietet Tools zur Generierung parametrisierter Versionen dieser Projektvorlagen

• Projekt-Bausteine können in einem Archetype (Template) erfasst werden, damit ein oder mehrere Aspekte eines Projekts auf andere Projekte hinzugefügt werden können

• Durch Archetype kann man J2EE-Entwicklung innerhalb seiner Organisation standardisieren

54

ArchetypesIn wenigen Sekunden kann ein neuer Benutzer ein funktionierendes Maven-Projekt erstellen!!

Einige verfügbare Archetypes:

Es stehen hunderte Archetypes zur Verfügung:http://docs.codehaus.org/display/MAVENUSER/Archetypes+List

In der Console: mvn archetype:generate > archetypes.txt

55

Hands on Maven

Maven Tutorial - Getting Started in 30 minutes:

http://maven.apache.org/guides/getting-started/

V –Maven Test DriveBuild Automation & Dependency Management

57

Maven Test Drive: CGI PizzaShop

CGI’s wächst weiter… Willkommen bei CGI’s PizzaShop!!

• Wir brauchen ein SVN repo:Goin’ to the cloud! www.assembla.com

• Quell-Code herunterladen und lokal bearbeiten:

>svn co https://subversion.assembla.com/svn/ciexample/trunk/pizzashop

58

Bereitstellung von Tomcat und Maven:

• Tomcat: • Set CATALINA_HOME Pfad/zur/Tomcat/Verzeichnis• Set CATALINA_OPTS -Xms256m -Xmx512m -XX:MaxPermSize=512m• JAVA_HOME Pfad/zur/JDK/Verzeichnis• M2_HOME Pfad/zur/Maven/Verzeichnis• HOME• Zur %Path% variable hinzufügen: %***_HOME%/bin• In CATALINA_HOME/conf/tomcat-users.xml hinzufügen:<role rolename="tomcat"/> <role rolename="manager-script"/> <role rolename="manager-gui"/> <user username="tomcat" password="tomcat" roles="tomcat,manager-script,manager-gui"/>

• Maven:• In ~/.m2/settings.xml hinzufügen (wenn nicht vorhanden)

<server><id>tomcat</id><username>tomcat</username><password>tomcat</password></server>

Umfeld Bereitstellung

59

Umfeld Bereitstellung

Bereitstellung von Sonar und Selenium Server:

• Sonar: • conf/sonar.properties ändern• .war erzeugen: build-war.bat• .war in Tomcat webapps Verzeichnis kopieren• Alles andere kommt in Projekt-POM konfiguriert

• Selenium Server:• Wir brauchen nur: Firefox version 11• Alles andere kommt in Projekt-POM konfiguriert

60

Maven Test-Drive

• Startup Server:• CATALINA_HOME/bin/startup• Fehlerlos Deployment von WebApps bestätigen:

• http://localhost:8080/pizzashop• http://localhost:8080/sonar

• PizzaShop Maven Install• >mvn clean install

• PizzaShop Deployment• >mvn tomcat:redeploy

61

Maven Test-Drive

• PizzaShop statische Code-Analyse• >mvn sonar:sonar

• PizzaShop System Testing mit Selenium• >mvn selenium:selenese

• Dokumentation vom PizzaShop (Site und JavaDocs)• >mvn site

• Analyse von PizzaShop Projekt-Abhängigkeiten• >mvn dependency:analyze• >mvn dependency:analyze-report

62

Vielen Dank für eure Aufmerksamkeit!!