| Summary:
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
repositories
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
|
