Search Gradle plugins

com.gradle.build-scan

Gradle build scans provide deep insights to your build by sending information to the Gradle Cloud where your build is analyzed then sent back to you as a build scan for free. Alternatively, build scans can be published to a private Gradle Enterprise installation. See https://gradle.com for more information.

https://scans.gradle.com/plugin/

Version 1.6

Created 10 February 2017.

New in this version:

- Capture whether task outputs are cacheable and the reason if they are not.
- Capture network download activities.

Compatible with scans.gradle.com and Gradle Enterprise 2017.1 or later.
Other versions 

Build script snippet for plugins DSL for Gradle 2.1 and later:

plugins {
  id "com.gradle.build-scan" version "1.6"
}

Build script snippet for use in older Gradle versions or where dynamic configuration is required:

buildscript {
  repositories {
    maven {
      url "https://plugins.gradle.org/m2/"
    }
  }
  dependencies {
    classpath "com.gradle:build-scan-plugin:1.6"
  }
}

apply plugin: "com.gradle.build-scan"

Build script snippet for plugins DSL for Gradle 2.1 and later:

plugins {
  id("com.gradle.build-scan") version "1.6"
}

Build script snippet for use in older Gradle versions or where dynamic configuration is required:

buildscript {
  repositories {
    maven {
      url = uri("https://plugins.gradle.org/m2/")
    }
  }
  dependencies {
    classpath("com.gradle:build-scan-plugin:1.6")
  }
}

apply(plugin = "com.gradle.build-scan")

Why?

The new way to add plugins to a project is much more than a more convenient syntax. The new DSL is processed very differently to the old one. The new mechanism allows Gradle to determine the plugins in use very early and very quickly. This allows Gradle to do smart things such as:

  • Optimize the loading and reuse of plugin classes.
  • Allow different plugins to use different versions of dependencies.
  • Provide editors detailed information about the potential properties and values in the buildscript for editing assistance.

This requires that plugins be specified in a way that Gradle can easily and quickly extract, before executing the rest of the build script. It also requires that the definition of plugins to use be somewhat static.

There are some key differences between the new plugin mechanism and the “traditional” apply() method mechanism. There are also some constraints, some of which are temporary limitations while the mechanism is still being developed and some are inherent to the new approach.

Constrained syntax.

The new plugins {} block does not support arbitrary Groovy code. It is constrained, in order to be idempotent (produce the same result every time) and side effect free (safe for Gradle to execute at any time).

The form is: 

plugins {
    id «plugin id» version «plugin version»
}

Where «plugin version» and «plugin id» must be constant, literal, strings. No other statements are allowed; their presence will cause a compilation error.

The plugins {} block must also be a top level statement in the buildscript. It cannot be nested inside another construct (e.g. an if-statement or for-loop).

Can only be used in build scripts.

The plugins {} block can currently only be used in a project's build script. It cannot be used in script plugins, the settings.gradle file or init scripts.

Future versions of Gradle will remove this restriction.

Cannot be used in conjunction with subprojects {}, allprojects {} etc.

It is not possible to use the familiar pattern of applying a plugin to multiple projects at once using subprojects {} etc. at the moment. There is currently no mechanism for applying a plugin to multiple projects at once. At the moment, each project that requires a plugin must declare so in the plugins {} block in its buildscript.

Future versions of Gradle will remove this restriction.

If the current limitations of the new plugin mechanism are problematic for your build, the recommended approach is to use the “traditional” mechanism for the time being.