Gradle Enterprise 2019.1

Gradle Enterprise 2019.1 brings the insights of build scans and the acceleration through build caching to Apache Maven™ builds. Whether you are migrating to Gradle or are committed to Maven for the future, Gradle Enterprise can make your Maven builds faster today.

For Gradle builds, configuration time profiling has been made more accurate through intelligent accounting of time spent in container callbacks, which are a common feature of Gradle build configuration for most builds. This makes it easier to find slow configuration code, particularly in Android builds that make extensive use of container callbacks.

Read on for more details.

Use version 1.0.2 of the Gradle Enterprise Maven extension, and version 2.2.1 of the Gradle build scan plugin for optimal usage of Gradle Enterprise.

Highlights

Apache Maven build scan insights and build cache acceleration

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.

If you are already using Gradle Enterprise, please note that Maven functionality is not enabled for existing licenses. Please contact us if you would like to expand your usage to Maven builds.

More accurate configuration time profiling for Gradle builds

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.

More accurate configuration time profiling requires Gradle 5.1+ and build scan plugin 2.2+.

Upgrade notes

If upgrading from a version of Gradle Enterprise prior to 2018.5, be sure to also consult the release notes for all interim versions.

Prolonged first startup after upgrade

This release contains a database structure change that may prolong the first startup after upgrading, depending on the number of build scans stored. With modest hardware, the change is expected to take roughly one minute per 100,000 build scans to complete. If your installation currently stores many build scans, please plan for an appropriate downtime window for the upgrade.

Delayed display of total count for scan list search results

In order to display scan search results sooner, the calculation of the total number of scans is deferred until after the initial page has been displayed. For searches that return millions of build scans, there may be a noticeable delay in the display of this total count.

Changes

Mar 04, 2019
  • [FIX] Build scan received after maintenance may be corrupted if cached data was deleted
Mar 01, 2019
  • [FEATURE] Build scans for Apache Maven™ builds
  • [FEATURE] Build caching for Apache Maven™ builds
  • [FEATURE] More accurate configuration time profiling of container callbacks
  • [FEATURE] Configuration of default roles for new user accounts with locally managed permissions
  • [FIX] Local user details cannot be edited when using an identity provider and locally managed permissions
  • [FIX] Builds uploaded shortly before a system shutdown are not processed on startup
  • [FIX] Builds with many deprecation notices are not processed correctly (requires build scan plugin 2.2)