Re: Now I’ve got it running and I’d like to show everyone how much faster it is than Maven… except I can’t. It isn’t faster. It’s about the same.
… just a ‘side note’ …
We’ve switched to Gradle from Maven and are running on Gradle for roughly 1.5 year. I would say that in terms of full ‘clean’ build they are indeed ‘about the same’ (note: I see you did not try executing MAVEN in multi-threaded mode – something like mvn clean install -T 8 - in our case it reduced build time by 60-70%).
The killer feature of Gradle is its flexibility in terms of configuration – we have roughly 400 modules in main part of the project - most of them are of 3-4 typical types. Gradle can inject external configuration scripts via ‘apply from’ and by using this feature overall size of build configuration reduced 100 times – type of the module is now encoded in the module folder name, e.g. via suffix ‘-api’, ‘-impl’, ‘-web’ and 99% of configuration is performed from root build.gradle via invocation of ‘api.gradle’ and so on … this is a bit oversimplified, but just to give an idea. (Note: configuring Gradle is also not a piece of cake – on large-scale projects. It took from us roughly 1 FTE-month to make initial build with Gradle so that all features of previous MAVEN build were still in place – missing intellisense for DSL, missing plugins, glitches with integration of 3rd party staff and so on).
In terms of performance I would say you can get significant performance difference vs. MAVEN only on incremental builds.
-
Unlike maven Gradle does check for non-changed code and builds only required parts (same can be done in MAVEN via some hacks, but – they are hacks)
-
Gradle has ‘configureondemand’ feature – this way build of individual sub-module can be significantly faster, i.e. out of 400 only 40 required modules will be initialized. Though this feature has few problems:
-
Build configuration should be thoroughly crafted - i.e. never use ‘projects.all’ or ‘subprojects.all’ – this triggers configuration of ‘all’ modules. Instead – use in root project
gradle.beforeProjector ‘gradle.afterProject’ -
‘parallel’ and ‘configureondemand’ are ‘incubating’ features – as long as I use Gradle
– various unexpected things may happen (and some-time build fails somewhere in Gradle’s internals - some time it takes days to identify the root cause). For example Gradle itself fails to build when ‘configureondemand’ is turned ‘on’ (see Cannot build official Gradle repo).