46

The Signing Plugin

The signing plugin adds the ability to digitally sign built files and artifacts. These digital signatures can then be used to prove who built the artifact the signature is attached to as well as other information such as when the signature was generated.

The signing plugin currently only provides support for generating PGP signatures (which is the signature format required for publication to the Maven Central Repository).

46.1. Usage

To use the Signing plugin, include in your build script:

Example 46.1. Using the Signing plugin

build.gradle

apply plugin: 'signing'

46.2. Signatory credentials

In order to create PGP signatures, you will need a key pair (instructions on creating a key pair using the GnuPG tools can be found in the GnuPG HOWTOs). You need to provide the signing plugin with your key information, which means three things:

The public key ID (an 8 character hexadecimal string).

The absolute path to the secret key ring file containing your private key.

The passphrase used to protect your private key.

These items must be supplied as the property projects signing.keyId, signing.password and signing.secretKeyRingFile respectively. Given the personal and private nature of these values, a good practice is to store them in the user gradle.properties file (described in Section 14.2, “Gradle properties and system properties”).

Page 254 of 343

signing.keyId=24875D73

signing.password=secret

signing.secretKeyRingFile=/Users/me/.gnupg/secring.gpg

If specifying this information in the user gradle.properties file is not feasible for your environment, you can source the information however you need to and set the project properties manually.

import org.gradle.plugins.signing.Sign

gradle.taskGraph.whenReady { taskGraph ->

if (taskGraph.allTasks.any { it instanceof Sign }) {

// Use Java 6's console to read from the console (no good for a CI env Console console = System.console()

console.printf "\n\nWe have to sign some things in this build.\n\nPlea

def id = console.readLine("PGP Key Id: ")

def file = console.readLine("PGP Secret Key Ring File (absolute path): def password = console.readPassword("PGP Private Key Password: ")

allprojects { ext."signing.keyId" = id }

allprojects { ext."signing.secretKeyRingFile" = file } allprojects { ext."signing.password" = password }

console.printf "\nThanks.\n\n"

}

}

46.3. Specifying what to sign

As well as configuring how things are to be signed (i.e. the signatory configuration), you must also specify what is to be signed. The Signing plugin provides a DSL that allows you to specify the tasks and/or configurations that should be signed.

46.3.1. Signing Configurations

It is common to want to sign the artifacts of a configuration. For example, the Java plugin configures a jar to built and this jar artifact is added to the archives configuration. Using the Signing DSL, you can specify that all of the artifacts of this configuration should be signed.

Example 46.2. Signing a configuration

build.gradle

signing {

sign configurations.archives

}

This will create a task (of type Sign) in your project named “signArchives”, that will build any ar artifacts (if needed) and then generate signatures for them. The signature files will be placed alongside the artifacts being signed.

Page 255 of 343

Example 46.3. Signing a configuration output

Output of gradle signArchives

> gradle signArchives :compileJava :processResources :classes

:jar

:signArchives

BUILD SUCCESSFUL

Total time: 1 secs

46.3.2. Signing Tasks

In some cases the artifact that you need to sign may not be part of a configuration. In this case you can directly sign the task that produces the artifact to sign.

Example 46.4. Signing a task

build.gradle

task stuffZip (type: Zip) { baseName = "stuff"

from "src/stuff"

}

signing {

sign stuffZip

}

This will create a task (of type Sign) in your project named “signStuffZip”, that will build the input task's archive (if needed) and then sign it. The signature file will be placed alongside th artifact being signed.

Example 46.5. Signing a task output

Output of gradle signStuffZip

> gradle signStuffZip :stuffZip :signStuffZip

BUILD SUCCESSFUL

Total time: 1 secs

For a task to be “signable”, it must produce an archive of some type. Tasks that do this are theTar

, Zip, Jar, War and Ear tasks.

Page 256 of 343

46.3.3. Conditional Signing

A common usage pattern is to only sign build artifacts under certain conditions. For example, you may not wish to sign artifacts for non release versions. To achieve this, you can specify that signing is only required under certain conditions.

Example 46.6. Conditional signing

build.gradle

version = '1.0-SNAPSHOT'

ext.isReleaseVersion = !version.endsWith("SNAPSHOT")

signing {

required { isReleaseVersion && gradle.taskGraph.hasTask("uploadArchives") sign configurations.archives

}

In this example, we only want to require signing if we are building a release version and we are going to publish it. Because we are inspecting the task graph to determine if we are going to be publishing, we must set the signing.required property to a closure to defer the evaluation. See SigningExtension.setRequired() for more information.

46.4. Publishing the signatures

When specifying what is to be signed via the Signing DSL, the resultant signature artifacts are automatically added to the signatures and archives dependency configurations. This means that if you want to upload your signatures to your distribution repository along with the artifacts you simply execute the uploadArchives task as normal.

46.5. Signing POM files

When deploying signatures for your artifacts to a Maven repository, you will also want to sign the published POM file. The signing plugin adds a signing.signPom() (see:

SigningExtension.signPom()) method that can be used in the beforeDeployment() block

in your upload task configuration.

Example 46.7. Signing a POM for deployment

build.gradle

uploadArchives { repositories {

mavenDeployer {

beforeDeployment { MavenDeployment deployment -> signing.signPom(d

}

}

}

When signing is not required and the pom cannot be signed due to insufficient configuration (i.e. no

Page 257 of 343

credentials for signing) then the signPom() method will silently do nothing.

Page 258 of 343

47

C++ Support

The Gradle C++ support is in very early stages of development. Please be aware that the DSL and other configuration may change in later Gradle versions.

The C++ plugins add support for building software comprised of C++ source code, and managing the process of building “native” software in general. While many excellent build tools exist for thi space of software development, Gradle brings the dependency management practices more traditionally found in the JVM development space to C++ developers.

The following platforms are supported:

Operating	Compiler	Notes
System
Linux	GCC	Tested with GCC 4.6.1 on Ubuntu 11.10
Mac OS X	GCC	Tested with XCode 4.2.1 on OS X 10.7
Windows	Visual	Tested with Windows 7 and Visual C++ 2010
	C++
Windows	MinGW	Tested with Windows 7 and MinGW 4.6.2. Note: G++ support is
		currently broken under cygwin

Currently, there is no direct support for creating multiple variants of the same binary (e.g. 32 bit vs. 64 bit) and there is no direct support for cross platform source configuration (à la autoconf) at this time. Support for different compiler chains, managing multiple variants and cross platform source configuration will be added over time, making Gradle a fully capable build tool for C++ (and other “native” language) projects.

Page 259 of 343