JCrete2014:GradleBuilds

{{jcrete-report-2014
 * title = Gradle (Build Madness?)
 * convenor = Massimo Calderoni / Andres Almiray
 * participants =
 * Giorgos Saslis
 * Kerstin Buchacker
 * Mike Cripps
 * Niels Wind
 * Jesper Udby
 * Anton Arhipov
 * Tasos Zervos
 * summary =

{{EmbedMedia }} In this session a number of build tools were briefly discussed with the focus being Gradle.
 * Width=295
 * Align=right
 * License=CC-BY-SA
 * Source=Session_1.3_Gradle_Build_Madness.ogg
 * Caption=Gradle (Build Madness?)
 * Author=JCrete2014
 * oggurl=http://commons.wikimedia.org/wiki/File:Session_1.3_Gradle_Build_Madness.ogg

tools mentioned
The tools discussed/mentioned included

build tools
 * gradle and gradle plugins
 * maven
 * ant and ivy
 * grunt

repositories
 * bintray and jcenter
 * maven central
 * github

repository servers
 * nexus
 * artifactory

continuous build servers
 * jenkins

test and coverage tools
 * cobertura
 * jacoco

integrated development environments and editors
 * vim
 * textmate (MacOS)
 * intellij
 * eclipse
 * netbeans

environment management
 * groovy environment manager (Unix)

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 ).
 * 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 ).
 * 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 }}
 * recommendations =
 * 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.