Gradle For Beginners (Serbian Developer Conference 2013 english)

1,746 views
1,579 views

Published on

A Step-By-Step Introduction to Gradle leading to a full build script for a project.

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,746
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
33
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Gradle For Beginners (Serbian Developer Conference 2013 english)

  1. 1. Gradle for Beginners Coding Serbia, 18.10.2013 Joachim Baumann
  2. 2. Gradle for Beginners •  Build-Management –  Needs –  Wishes •  Gradle - Basics •  Configuration and Execution Phase •  Groovy – Short Overview •  Plug-ins – Basics •  Our –  –  –  –  –  –  First Project Directory Structure Dependencies Manipulating the Jar Tests Quality Assurance Publishing the Artefacts
  3. 3. What do we need from a Build-Management System? •  •  •  •  •  •  •  •  •  •  Translating the Source Code (using a compiler) Linking the Results Check out the source code from a repository (optional) Creating Tags (optional) Execution of different types of tests: Examples: –  Unit Tests for single Classes –  Module or Component Tests –  Integration Tests –  Functional and Non-Functional System Tests –  Automated Acceptance Tests Detailed Test Reports combining all Test Results (optional) Packing the Result (e.g., into a Jar, War or Ear) Transfer the Results to the different Stages / Test Systems and Execution of the respective Tests (optional) Support for multi-language Projects Creation of Documentation and Release Notes
  4. 4. What do we wish for in our Build-Management System? •  Explicit Support of the Workflow implemented by the BuildManagement-System •  Simple Modifiability and Extensibility of the Workflow to adapt to local processes •  Readability and self-documentation of the notation in the build script •  Use of sensible conventions (e.g., where to find the sources) •  Simple change of the conventions to adap to local environment •  Incremental Build that can identify artefacts that have already been built •  Parallelisation of independent steps in the workflow to minimize waiting •  Programmatic access to all artefacts being created by the build •  Status reports that summarize the current state of the build
  5. 5. Gradle - Basics •  Gradle uses build scripts which are named build.gradle •  Every build script is a Groovy script •  Two very important Principles –  Convention over Configuration –  Don’t Repeat Yourself •  Gradle creates a dynamic model of the workflow as a Directed Acyclic Graph (DAG) •  (Nearly) Everything is convention and can be changed tset tseTelipmoc dliub elipmoc elbmessa
  6. 6. Configuration Phase •  •  •  •  Executes the build script The contained Groovy- and DSL-commands configure the underlying object tree The root of the object tree is the Project object –  Is directly available in the script (methods and properties) Creation of new Tasks that can be used Manipulation of the DAG •  Our first script build.gradle •  println ”Hello from the configuration phase"
  7. 7. Execution Phase •  Executes all tasks that have been called (normally on the command line) •  For a task that is executed every task it depends on is executed beforehand •  Gradle uses the DAG to identify all task relationships tset tseTelipmoc dliub elipmoc elbmessa
  8. 8. Task Definition •  •  Takes an (optional) configuration closure Alternatively: can be configured directly •  •  The operator << (left-shift) appends an action (a closure) to this task’s list of actions Equivalent to doLast() •  Insert at the beginning of the list with doFirst() task halloTask halloTask.doLast { print "from the " } halloTask << { println "execution phase" } halloTask.doFirst { print "Hello " } task postHallo (dependsOn: halloTask) << { println "End" } postHallo { // configuration closure dependsOn halloTask }
  9. 9. Groovy – Short Overview •  Simplified Java Syntax –  Semicolon optional –  GString –  Everything is an Object –  Simplification e.g., “println” •  Scripts •  Operator Overloading –  Predefined •  Example << •  Operator for secure navigation a.?b –  You can provide your own implementations •  Named Parameters •  Closures •  Collection Iterators
  10. 10. Plug-ins - Basics •  Plug-ins encapsulate functionality •  Can be written in any VM-language –  Groovy is a good choice •  Possible Plug-in Sources –  Plug-ins packed with Gradle –  Plug-ins included using URLs (don’t do it) –  Plug-ins provided by repositories (use your own repository) –  Self-written Plug-ins (normally in the directory buildSrc) •  Plug-ins –  Extend objects –  Provide new objects and / or abstractions –  Configure existing objects •  Plug-ins are load with the command apply plugin apply plugin: ‘java’
  11. 11. Our first Project •  We use the Java Plug-in •  Default paths used by the Java Plug-in –  Derived from Maven Conventions
  12. 12. The Class 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; } }
  13. 13. Manipulation of the Manifest •  Every Jar-Archive contains a file MANIFEST.MF •  Is generated by Gradle (see directory build/tmp/jar/MANIFEST.MF) •  Contains information e.g., about the main class of the jar •  Can be changed jar { manifest { attributes 'Main-Class': 'de.gradleworkshop.HelloWorld' } } •  Alternatively jar.manifest.attributes 'Main-Class': 'de.gradleworkshop.HelloWorld'
  14. 14. Tests 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("wrong number of results", 1, res.size()); } }
  15. 15. Configurations and Dependencies •  Gradle defines Configuration Objects. These encapsulate –  Dependency Information –  Paths to Sources and Targets –  Associated Artefacts –  Additional Configuration Information •  Tasks use these Configurations •  For most pre-defined Task a Configuration exists –  compile, testCompile, runtime, testRuntime •  •  Dependencies are defined using the key word dependencies Maven-like notation for the dependencies dependencies { testCompile group: 'junit', name: 'junit', version: '4.+’ }
  16. 16. Repositories •  Repositories provide libraries (normally jar archives) •  You can define Ivy or Maven Repositories, both public and private •  Predefined Repositories –  JCenter –  Maven Central –  Local Maven Repository (~/.m2/repository) •  Repositories are defined using the keyword repositories repositories { mavenLocal() } repositories { jcenter() mavenCentral() } •  Multiple Repositories can be defined
  17. 17. The Application Plug-in •  The Application-Plug-in –  Adds a Task run –  Creates start scripts, that can be used with the Task run –  Creates a Task distZip, that packs all necessary files into a ziparchive –  Definition of the Main Class mainClassName = "de.gradleworkshop.HelloWorld" –  Usage with apply plugin: 'application'
  18. 18. Using TestNG •  Very Simple dependencies { testCompile group: 'org.testng', name: 'testng', version: '6.+' } test { useTestNG() }
  19. 19. Test Class for 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("Wrong Number of Entries", 1, res.size()); } }
  20. 20. Quality Assurance •  Support for PMD, Checkstyle, Findbugs, Emma, Sonar … •  Example PMD apply plugin: 'pmd' pmdMain { ruleSets = [ "basic", "strings" ] ignoreFailures = true } •  Another Example configuring all Tasks of Type Pmd using withType() tasks.withType(Pmd) { ruleSets = [ "basic", "strings" ] ignoreFailures = true ruleSetFiles = files('config/pmd/rulesets.xml') reports { xml.enabled false html.enabled true } }
  21. 21. Publishing the Artefacts •  Gradle defines for every Configuration a Task upload<Configuration> –  Builds and publishes the Artefact belonging to the Configuration •  The Java-Plug-in creates a Configuration archives, which contains all artefacts created in the Task jar –  uploadArchives is the natural choice for publishing the artefacts •  Use of the Maven-Plug-in with apply plugin: ‘maven’ –  Doesn’t use the normal repository (intentionally) apply plugin: 'maven' version = '0.1-SNAPSHOT' group = 'de.gradleworkshop' uploadArchives { repositories { flatDir { dirs "repo" } mavenDeployer { repository (url : "file://$projectDir/mavenRepo/") } } }
  22. 22. The whole Script (less than 20 lines) apply plugin: 'java' apply plugin: 'pmd' jar.manifest.attributes 'Main-Class': 'de.gradleworkshop.HelloWorld' pmdMain { ruleSets = [ "basic", "strings" ] ignoreFailures = true } repositories { mavenCentral() } dependencies { testCompile group: 'junit', name: 'junit', version: '4.+' } apply plugin: ‘maven’ version = '0.1-SNAPSHOT’ group = 'de.gradleworkshop’ uploadArchives { repositories { flatDir { dirs "repo" } mavenDeployer { repository (url : "file:///gradleWS/myRepo/") } } }
  23. 23. Recap •  We have, with Gradle –  Built an Application –  Created Tests and executed them –  Used an alternative Test Framework TestNG –  Used Quality Assurance –  Uploaded the Artefacts into two Repositories •  You now know everything to build normal Projects with Gradle •  Gradle –  Is simple –  Easily understood –  Has sensible conventions –  That can be easily changed •  Gradle adapts to your needs
  24. 24. Questions? Dr. Joachim Baumann codecentric AG An der Welle 4 60322 Frankfurt Joachim.Baumann@codecentric.de www.codecentric.de blog.codecentric.de 24  

×