Gradle (Build Madness?)

From WikiEducator
Jump to: navigation, search

Gradle (Build Madness?)
Convenor: Massimo Calderoni / Andres Almiray
Gradle (Build Madness?) - JCrete2014

Free content media streamed from Wikimedia Commons

Download: .ogg

In this session a number of build tools were briefly discussed with the focus being Gradle.

tools mentioned

The tools discussed/mentioned included

build tools


repository servers

continuous build servers

test and coverage tools

integrated development environments and editors

environment management

discussion items

Andres was the gradle expert in this session and he provided pretty much all gradle information.

  • support for C/C++ compilation difficult in Java-focused build tools, although this is currently being developed for gradle (see [1]).
  • docmentation for gradle seems better than documentation for maven, gradle community currently being more responsive than the maven community
  • gradle plugins are more aware of each other than maven plugins
  • gradle can consume maven repositories (same as ivy); publishing to repositories is being actively developed in gradle and therefore several publishing plugins exist in parallel (see also [2]).
  • if you ar publishing to bintray, this will automatically synchronise with maven central; if an artifact is requested from bintray, which is not yet cached, bintray will attempt to retrieve it from maven central; bintray has a good integration with artifactory;
  • gradle can work with the grunt build system through a plugin
  • gradle has a cache in which it keeps information on which artifacts were built when and whether they need to be rebuilt due to the latest changes made; this may save considerable time on a build, but it may require the network time synchronisation to be set up properly
  • cobertura may run tests repeatedly, for example once to calculate the coverage and once when producing the maven site reports; jacoco is smarter here;
  • the gradle lifecycle is more flexible than the maven lifecycle; maven always runs through the complete lifecycle, whereas you can give hints to gradle to skip certain phases
  • creating plugins in gradle seems easier than creating plugins in maven
  • if you want to go further than just creating a jar in gradle, you may run into similar problems as with maven; there is some support for other packaging formats (e.g. rpm, debian) through plugins.
  • versions on deployment can be handled, for example, by integrating the jenkins build number into the artifact during the gradle build
  • gradle does not yet support the bill-of-material (bom) files, which are used in maven to fully specify all dependencies of a build
  • gradle uses conventions and the build definition specifies, how much the project deviates from the conventions

Recommendations go here

  • Andres recommendation is to always give gradle a try, both to migrate an existing maven project or when starting a new project, even when you do not have prior gradle experience. His main reasons are the better documentation and faster build times.