In this session a number of build tools were briefly discussed with the focus being Gradle.
The tools discussed/mentioned included
continuous build servers
test and coverage tools
integrated development environments and editors
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