A Step-By-Step Introduction to Gradle leading to a full build script for a project. This presentation is in german

1. Gearconf - Gradle Workshop
Gradle für Einsteiger

2. Dr. Joachim Baumann
Ausbildung
1986-­‐1992
1994-­‐1999
1999-­‐2000
InformaFk
UniversiYät
StuYgart
PromoFon
Universität
StuYgart,
Universität
Genf
Postdoc
Universität
StuYgart
Referenzen
(Auszug)
n
n
Beruflicher
Werdegang
1993 ANT
Bosch
Telecom,
Soware-­‐Entwickler
2000 COSS
Sowaretechnik
AG,
Bereichsleiter
Produktentwicklung
und
Forschung
n
2001 Junidas
GmbH,
Geschäsführer
2005 Xinaris
GmbH,
Geschäsführer
2007 Cirquent
GmbH,
Leitung
Competence
Center
iBPM,
Director
Shoring
2012 codecentric
AG,
Geschäsführer
Frankfurt
n
Schwerpunkte
n
n
n
n
n
n
Architektur
großer
Systeme
Open-­‐Source-­‐Produkte
KommunikaFonsnetze,
Mobile
CompuFng,
Verteilte
Systeme,
Datenbanken
Training,
Coaching,
Vorträge
Agile
Methoden
Big
Data
Nürnberger
Versicherungsgruppe,
Nürnberg
p Absatzplanungssystem
der
Nürnberger
Versicherung
p Technischer
Projektleiter
p Architekt
FIDUCIA
IT
AG,
Karlsruhe
p Architekturberatung
p Übernahme
kriFscher
Projekte
p Qualitätssicherung
p Coaching
NTT
DATA,
Tokyo
p Entwurf
einer
neuen
agil
basierten
Methode
für
24-­‐
Stunden
Entwicklung
p VerifikaFon
der
Methode
in
einem
von
3
Vergleichsprojekten
p Preis
für
das
Projekt
von
NTT
DATA
ArFkel,
Bücher,
Vorträge
p 3
Bücher
p Über
40
ArFkel
p Vorträge
auf
int.
und
deutschen
Konferenzen
p Beispiele
— „Groovy:
Grundlagen
und
fortgeschriYene
Techniken“,
d.punkt
Verlag,
600
S.
— „Groovy:
Grundlagen“
in
iX-­‐Sonderhe
Java
Kompakt
1/2009
„Gradle:
Ein
kompakter
EinsFeg
in
das
Build-­‐
Management-­‐System“,
d.punkt-­‐Verlag,
260
S.

3. codecentric auf einen Blick
Das Unternehmen codecentric AG
• Europaweit
• 10 Standorte
• 200 Spezialisten
• 4 Bereiche
• Beratung
• Agile Software Factory
• Performance Solutions
• Meettheexperts
(Schulungen & Workshops)
Hamburg
Niederlande
Berlin
Düsseldorf
Solingen
Frankfurt
Karlsruhe
München
Schweiz
Bosnien
und
Herzegowina
Serbien
Datum / Unternehmensvorstellung
3

4. Werte der Codecentric

5. Erwartete Funktionalität eines Build-Management-Systems
•
•
•
•
•
•
•
•
•
•
Übersetzung von Quelltexten
Linken der Ergebnisse
Checkout der Quelltexte aus dem Versionsverwaltungssystem (kann ausgelagert
werden)
Setzen von Tags (kann ausgelagert werden).
Ausführen verschiedener Arten von Tests. Beispiele sind:
– Unit-Tests für einzelne Klassen
– Modul- oder Komponententests
– Integrationstests
– Funktionale und nichtfunktionale Systemtests
– Automatisierte Akzeptanztests
Detaillierte Test-Reports, die die Testergebnisse übersichtlich zusammenfassen.
Packen des Resultats (z.B. eine Jar-, War- oder Ear-Datei)
Transfer des Resultats zu den verschiedenen Testsystemen und Ausführung
entsprechender Testarten (häufig durch Build-Server übernommen).
Unterstützung für polyglotte Projekte.
Erzeugung von Dokumentation und Release Notes.

6. Wünsche an ein Build-Management-System
•
•
•
•
•
•
•
•
•
Explizite Unterstützung des Workflows, der durch das Build- ManagementSystem implementiert wird.
Leichte Anpass- und Erweiterbarkeit des Workflows, um sich an lokale
Vorgehensmodelle anpassen zu können.
Leichte Lesbarkeit und selbsterklärende Notation der Sprache des Build-Skripts.
Verwendung von Konventionen, um vernünftige Vorgabewerte für die
verschiedenen Schritte des Workflows zu haben (wie zum Bei-spiel die Orte, an
denen sich die Quelltexte befinden).
Leichte Änderbarkeit der Vorgabewerte für die Anpassung an die lokale
Umgebung.
Inkrementeller Build, der erkennt, welche Artefakte schon erzeugt sind.
Parallelisierung von unabhängig ausführbaren Schritten des Workflows, um die
Wartezeit so kurz wie möglich zu halten.
Zugriff auf alle Artefakte, die durch den Build erzeugt wurden.
Status-Reports, die den aktuellen Zustand des Builds zusammenfassen.

7. Gradle für Einsteiger
•
Wichtig: Selbermachen, nicht zuschauen
•
Installation
•
Grundlagen
•
Konfigurations- und Ausführungsphase
•
Kurzüberblick Groovy
•
Plug-ins - Grundlagen
•
Ein
–
–
–
–
–
•
Veröffentlichung der Artefakte
Projekt
Verzeichnisstruktur
Abhängigkeiten
Manipulation der Jar-Datei
Tests
Qualitätssicherung

8. Grundlagen von Gradle
•
Gradle verwendet Build-Skripte, die build.gradle heißen
•
Jedes Build-Skript ist ein Groovy-Skript
•
Zwei sehr wichtige Prinzipien
– Convention over Configuration
– Don’t Repeat Yourself
•
Gradle erzeugt ein dynamisches Modell des Workflows in Form eines DAG
•
Alles ist änderbar
tset
tseTelipmoc
dliub
elipmoc
elbmessa

9. Installation
•
Herunterladen von Java
www.javasoft.com
•
Herunterladen von Gradle
www.gradle.org
•
Optional Groovy
groovy.codehaus.org
•
•
•
•
•
Installation unter Windows: Verzeichnis Program FilesGradlegradle-1.8
Installation unter OS X: /Library/Gradle/gradle-1.8
Installation unter Linux: /usr/local/Gradle/gradle-1.8
Symbolischen Link setzen
Pfad setzen
•
•
Texteditor
Shell
•
Falls noch viele herunterladen müssen, dann über USB-Stick

10. Konfigurationsphase
•
•
•
•
Es wird das Gradle-Build-Skript ausgeführt
Die Groovy- und DSL-Befehle konfigurieren das Objektgeflecht
Das Projekt-Objekt ist die Wurzel des Geflechts
– Wird direkt zur Verfügung gestellt
Erzeugen neuer Tasks, die ausgeführt werden können
•
Erstes Skript in der Datei build.gradle
println "Hallo aus der Konfigurationsphase"

11. Ausführungsphase
•
Führt alle aufgerufenen Tasks aus (normalerweise Kommandozeile)
•
Vorher werden alle Tasks ausgeführt, von denen dieser abhängig ist
•
Hierfür wird der DAG ausgewertet, um die Abhängigkeiten zu bestimmen

12. Definition eines Tasks
•
Erhält eine Konfigurations-Closure (optional) als Argument, alternativ direkte
Argumente
•
•
Mit << (left-shift) können Aktionen an die Liste der Aktionen angehängt werden
Äquivalent zu doLast()
•
Einfügen am Anfang der Liste mit doFirst()
task halloTask
halloTask.doLast { print "aus der " }
halloTask << { println "Ausführungsphase" }
halloTask.doFirst { print "Hallo " }
task postHallo (dependsOn: halloTask) << {
println “Ende”
}

13. Kurzüberblick Groovy
•
Vereinfachte Java-Syntax
– Semikolon optional
– Gstring
– Grundsätzliche Verwendung von Objekten
– Abkürzungen wie “println”
•
Skripte
•
Operatorüberladung
– Vorgegebene
• Beispiel <<
• Operator für sichere Navigation a.?b
– Eigene möglich
•
Benannte Parameter
•
Closures
•
Collection-Iteratoren

14. Plug-ins - Grundlagen
•
Plug-ins kapseln Funktionalität
•
Können in beliebigen VM-Sprachen geschrieben sein
– Gute Wahl ist Groovy
•
Möglichkeiten
– Mitgelieferte Plug-ins
– Plug-ins, die über URLs geladen werden (nicht zu empfehlen)
– Plug-ins, die über Repositories geladen werden
– Plug-ins, die selbst geschrieben sind (meist im Verzeichnis buildSrc)
•
•
•
Erweitern Objekte
Stellen neue Objekte zur Verfügung
Konfigurieren existierende Objekte
•
Werden geladen über den Befehl apply plugin
apply plugin: ‘java’

15. Ein einfaches Projekt
•
Wir benutzen das Java-Plug-in
•
Default-Pfade des Java-Plug-ins (angelehnt an Maven)

16. Klasse HelloWorld
package de.gradleworkshop;
import java.util.ArrayList;
import java.util.List;
public class HelloWorld {
public static void main(String[] args) {
HelloWorld hw = new HelloWorld();
for(String greeting : hw.generateGreetingsData())
System.out.println(greeting);
}
public List<String> generateGreetingsData() {
List <String> greetings = new ArrayList <String>();
greetings.add("Hallo Welt");
return greetings;
}
}

17. Manipulation des Manifests
•
Jede Jar-Datei enthält eine Datei MANIFEST.MF (siehe build/tmp)
•
Diese kann verändert werden
•
Enthält unter anderem eine Startklasse für das Jar-Archiv
jar {
manifest {
attributes 'Main-Class': 'de.gradleworkshop.HelloWorld'
}
}
•
Alternativ
jar.manifest.attributes 'Main-Class': 'de.gradleworkshop.HelloWorld'

18. Tests
•
Platzieren der Testklassen in das richtige Verzeichnis sorgt für automatisches Übersetzen
package de.gradleworkshop;
import java.util.List;
import org.junit.*;
import static org.junit.Assert.*;
public class HelloWorldTest {
HelloWorld oUT;
@Before
public void setUp() {
oUT = new HelloWorld();
}
@Test
public void testGenerateGreetingsData() {
List<String> res = oUT.generateGreetingsData();
assertEquals("result contains wrong number of results", 1, res.size());
}
}

19. Konfigurationen und Abhängigkeiten
•
Gradle bietet Konfigurationsobjekte
– Bieten Abhängigkeitsinformationen
– Pfade zu Quellen und zu Zielen
– Zugehörige Artefakte
– Weitere Konfigurationsinformationen
•
Tasks hängen von Konfigurationen ab
•
Beispiele
– compile, testCompile, runtime, testRuntime
•
•
Abhängigkeiten werden über ein Schlüsselwort dependencies definiert
Maventypische Notation
dependencies {
testCompile group: 'junit', name: 'junit', version: '4.+’
}

20. Anbindung von Repositories
•
Repositories stellen die Jar-Archive zur Verfügung
•
Es lassen sich Ivy- und Maven-Repositories anbinden, öffentlich und privat
•
Spezielle Repositories
– Maven Central
– Lokales Maven Repository (~/.m2/repository)
•
Verwendund des Schlüsselworts repositories
repositories {
mavenLocal()
}
repositories {
mavenCentral()
}
•
Es können mehrere Repositories definiert werden

21. Weitere Plug-ins
•
Das Application-Plug-in
– Erzeugt Start-Skripte, die mit dem Task run verwendet werden können
– Ein Zip-Archiv mit dem Task distZip
– Setzen der Hauptklasse über
mainClassName = "de.gradleworkshop.HelloWorld"
– Verwendung mit apply plugin: 'application'

22. Verwendung von TestNG
•
Sehr einfach
dependencies {
testCompile group: 'org.testng', name: 'testng', version: '6.+'
}
test {
useTestNG()
}

23. Testklasse für TestNG
package de.gradleworkshop;
import java.util.List;
import static org.junit.Assert.assertEquals;
import static org.testng.AssertJUnit.*;
import org.testng.annotations.*;
public class TestHelloWorld {
HelloWorld oUT;
@BeforeTest
public void setUp() {
oUT = new HelloWorld();
}
@Test
public void testGenerateGreetingsData() {
List<String> res = oUT.generateGreetingsData();
assertEquals("Falsche Anzahl Einträge", 1, res.size());
}
}

24. Qualitätssicherung
•
Unterstützung für PMD, Checkstyle, Findbugs, Emma, Sonar
•
Beispiel für PMD
apply plugin: 'pmd'
pmdMain {
ruleSets = [ "basic", "strings" ]
ignoreFailures = true
}
•
Weiteres Beispiel unter Verwendung von withType()
tasks.withType(Pmd) {
ruleSets = [ "basic", "strings" ]
ignoreFailures = true
ruleSetFiles = files('config/pmd/rulesets.xml')
reports {
xml.enabled false
html.enabled true
}
}

25. Veröffentlichung der Artefakte
•
Gradle definiert für jede Konfiguration einen Task upload<Konfiguration>
– Baut und veröffentlicht die zur Konfiguration gehörenden Artefakte
•
Das Java-Plug-in erzeugt eine Konfiguration archives, die sämtliche im Task jar
erzeugten Artefakte enthält.
– uploadArchives kann also für die Veröffentlichung verwendet werden
•
Verwendung des Maven-Plug-ins mit apply plugin: ‘maven’
– Absichtlich keine Verwendung des “normalen” Repositories
apply plugin: ‘maven’
version = '0.1-SNAPSHOT’
group = 'de.gradleworkshop’
uploadArchives {
repositories {
flatDir { dirs "repo" }
mavenDeployer { repository (url : "file:///gradleWS/myRepo/") }
} }

26. Zusammenfassung
•
Wir haben Gradle programmiert und
–
–
–
–
–
Eine Applikation gebaut
Die Tests für die Applikation gemacht
Ein alternatives Test-Framework eingesetzt
Die Qualität gesichert
In ein lokales Repository hochgeladen
•
•
Damit können Sie jetzt normale Projekte problemlos mit Gradle bauen
Migration von anderen Build-Systemen zu Gradle ist einfach
•
Gradle
– ist einfach
– It leicht verständlich
– hat vernünftige Vorgaben
– kann leicht angepasst werden

27. Fragen?
Dr. Joachim Baumann
codecentric AG
An der Welle 4
60322 Frankfurt
Joachim.Baumann@codecentric.de
www.codecentric.de
blog.codecentric.de
Datum/ Fragen
27