Gradle Enterprise 2019.1

While helping many organizations adopt Gradle Enterprise for their Gradle builds, we have frequently been asked: Can you also help make our Maven builds faster? Now we can.

The Gradle Enterprise Maven extension enables using a local on-disk build cache and a remote build cache provided by Gradle Enterprise. The 1.0 release of the extension supports caching the compilation of Java source files and execution of tests.

Build caching works conceptually the same way for Maven builds as it does for Gradle builds. Execution of a goal can be avoided by reusing the outputs from a previous identical execution, potentially saving a tremendous amount of build time.

Build caching for Gradle has reduced build times for many software teams. Build caching for Maven is set to have an even greater impact due to Maven lacking other complimentary build acceleration features of Gradle such as incremental building.

The chart below shows build times for the popular Spring Boot project before and after Gradle Enterprise build cache acceleration for a clean build with no changes (executing “mvn clean package”).

In addition to providing build cache acceleration, the Gradle Enterprise Maven extension also provides build scan insights for each and every build. Build scans are a record of what happened during a build that is captured and visualized by Gradle Enterprise. They provide insights into the modules involved in a build and their relationships, the plugins used, the build environment, the time of each goal, and failure diagnostics. They also provide feedback on the effectiveness of the build cache and diagnostics for optimizing its usage.

Future versions of Gradle Enterprise will bring features currently only available for Gradle builds such as dependency visualisation and comparison, the performance dashboard, inputs comparison, and others, to Maven builds.

To learn more about using Gradle Enterprise with Maven, you can watch our introductory webinar, or register for our upcoming free online training. You can also create build scans for your Maven builds today at scans.gradle.com for free with your own project or the quickstart example project. See the Gradle Enterprise Maven extension user manual for more information on configuring your Maven builds to use Gradle Enterprise or scans.gradle.com, and the minimum version requirements for Maven and relevant plugins.

Gradle build scans provide a configuration time breakdown, profiling the time taken to execute the scripts and plugins that contribute the build logic. This profile has been improved to consider common types of configuration callbacks and to provide more useful feedback.

The time taken by such callbacks is now counted as part of the script or plugin that registered the callback instead of the script or plugin that triggered the callback. This means that the time is associated with where the code is, which is what will need to be changed to remove bottlenecks.

All callbacks registered with one of Gradle’s “domain object collections” are now accounted for in this manner. Callbacks are added to these containers with methods such as `withType()` or `all {}`. The most commonly used such container is the tasks container. Use of such callbacks is also particularly prominent in Android builds, via the flavors, buildTypes and variants containers.

The totals shown in the `Configuration` tab of the `Performance` section for each script or plugin now include the callback time. The component of the time that is contributed by callbacks for the script or plugin is itemized in its inspector.

This improvement makes it easier to find slow configuration time code that is implemented as a container callback.