Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Add local keyring file

Fetching remote keys can be quite expensive. In order to avoid lookups,

this commits introduces the ability to use a local keyrings file, found

alongside the verification metadata.

This file can either be generated using regular tools like GPG, or via

command-line by adding the `--export-keys` flag when generating the

verification metadata.

  1. … 19 more files in changeset.
Add local keyring file

Fetching remote keys can be quite expensive. In order to avoid lookups,

this commits introduces the ability to use a local keyrings file, found

alongside the verification metadata.

This file can either be generated using regular tools like GPG, or via

command-line by adding the `--export-keys` flag when generating the

verification metadata.

  1. … 19 more files in changeset.
Add local keyring file

Fetching remote keys can be quite expensive. In order to avoid lookups,

this commits introduces the ability to use a local keyrings file, found

alongside the verification metadata.

This file can either be generated using regular tools like GPG, or via

command-line by adding the `--export-keys` flag when generating the

verification metadata.

  1. … 19 more files in changeset.
Add local keyring file

Fetching remote keys can be quite expensive. In order to avoid lookups,

this commits introduces the ability to use a local keyrings file, found

alongside the verification metadata.

This file can either be generated using regular tools like GPG, or via

command-line by adding the `--export-keys` flag when generating the

verification metadata.

  1. … 19 more files in changeset.
Add local keyring file

Fetching remote keys can be quite expensive. In order to avoid lookups,

this commits introduces the ability to use a local keyrings file, found

alongside the verification metadata.

This file can either be generated using regular tools like GPG, or via

command-line by adding the `--export-keys` flag when generating the

verification metadata.

  1. … 19 more files in changeset.
Add local keyring file

Fetching remote keys can be quite expensive. In order to avoid lookups,

this commits introduces the ability to use a local keyrings file, found

alongside the verification metadata.

This file can either be generated using regular tools like GPG, or via

command-line by adding the `--export-keys` flag when generating the

verification metadata.

  1. … 19 more files in changeset.
Cache missing keys for 24 hours

This commit adds caching of missing keys for 24 hours. This avoids reaching out

to key servers always when a key is missing. Instead, we cache the result for

24 hours, and it's possible to refresh the keys using the `--refresh-keys` CLI

option.

  1. … 6 more files in changeset.
Cache missing keys for 24 hours

This commit adds caching of missing keys for 24 hours. This avoids reaching out

to key servers always when a key is missing. Instead, we cache the result for

24 hours, and it's possible to refresh the keys using the `--refresh-keys` CLI

option.

  1. … 6 more files in changeset.
Add dependency verification mode

This commit introduces a selection of the dependency verification

mode. There are 3 different modes: strict (default), lenient and

off.

The lenient mode has been added because dogfooding the feature showed

it could be painful to udpate the dependency verification

metadata file without such an option: often we want to diagnose

why a dependency is here, but as soon as the dependency

verification file is present, verification is active and immediately

fails the build.

This effectively prevents from using the usual tooling to check

where a dependency comes from. The workaround was to temporarily

rename the file, run the build, then rename again, which was tedious.

So, instead of adding a mode where verification would be totally

ignored, this commit introduces a mode where the errors are turned

into warnings. This doesn't totally silence the problems, which

makes them more visible to the developer.

The "off" mode is for use cases where users prefer not to deal

with upgrades locally, but want to see verification happening

on CI only.

  1. … 8 more files in changeset.
Add lenient dependency verification mode

This mode has been added because dogfooding the feature showed

it could be painful to udpate the dependency verification

metadata file without such an option: often we want to diagnose

why a dependency is here, but as soon as the dependency

verification file is present, verification is active and immediately

fails the build.

This effectively prevents from using the usual tooling to check

where a dependency comes from. The workaround was to temporarily

rename the file, run the build, then rename again, which was tedious.

So, instead of adding a mode where verification would be totally

ignored, this commit introduces a mode where the errors are turned

into warnings. This doesn't totally silence the problems, which

makes them more visible to the developer.

  1. … 5 more files in changeset.
Add dependency verification mode

This commit introduces a selection of the dependency verification

mode. There are 3 different modes: strict (default), lenient and

off.

The lenient mode has been added because dogfooding the feature showed

it could be painful to udpate the dependency verification

metadata file without such an option: often we want to diagnose

why a dependency is here, but as soon as the dependency

verification file is present, verification is active and immediately

fails the build.

This effectively prevents from using the usual tooling to check

where a dependency comes from. The workaround was to temporarily

rename the file, run the build, then rename again, which was tedious.

So, instead of adding a mode where verification would be totally

ignored, this commit introduces a mode where the errors are turned

into warnings. This doesn't totally silence the problems, which

makes them more visible to the developer.

The "off" mode is for use cases where users prefer not to deal

with upgrades locally, but want to see verification happening

on CI only.

  1. … 8 more files in changeset.
Add lenient dependency verification mode

This mode has been added because dogfooding the feature showed

it could be painful to udpate the dependency verification

metadata file without such an option: often we want to diagnose

why a dependency is here, but as soon as the dependency

verification file is present, verification is active and immediately

fails the build.

This effectively prevents from using the usual tooling to check

where a dependency comes from. The workaround was to temporarily

rename the file, run the build, then rename again, which was tedious.

So, instead of adding a mode where verification would be totally

ignored, this commit introduces a mode where the errors are turned

into warnings. This doesn't totally silence the problems, which

makes them more visible to the developer.

  1. … 5 more files in changeset.
Make selection of checksum algorithms mandatory

Instead of using a default list, the user has to choose

what checksums to generate when bootstrapping the dependency

verification file.

This is done because it will have an impact when checking

the dependencies: all checksums will be verified.

  1. … 7 more files in changeset.
Make selection of checksum algorithms mandatory

Instead of using a default list, the user has to choose

what checksums to generate when bootstrapping the dependency

verification file.

This is done because it will have an impact when checking

the dependencies: all checksums will be verified.

  1. … 7 more files in changeset.
Generate checksum file for dependency verification

This commit introduces the generation of a dependency

verification metadata file from the CLI. If the user

calls `--write-verification-metadata`, then an XML

file is generated (`gradle/verification-metadata.xml`).

This file will contain the checksums for all artifacts

required by a build, which includes:

- plugin artifacts

- jars and other artifacts requested via a `configuration`

- secondary artifacts (javadocs, classifiers, ...)

It does NOT include metadata of those artifacts (pom files,

ivy files, Gradle Module metadata).

It isn't required to resolve any configuration to get this

behavior: the build will automatically process all resolvable

configurations and _try_ to resolve them automatically. All

artifacts resolved during this process are going to be automatically

downloaded (if not already). Then SHA-1 and SHA-512 checksums

are computed for all those artifacts.

The current format is an XML file planned to support more than

just artifacts: module metadata AND signature information is

planned.

See #11398

  1. … 32 more files in changeset.
Generate checksum file for dependency verification

This commit introduces the generation of a dependency

verification metadata file from the CLI. If the user

calls `--write-verification-metadata`, then an XML

file is generated (`gradle/verification-metadata.xml`).

This file will contain the checksums for all artifacts

required by a build, which includes:

- plugin artifacts

- jars and other artifacts requested via a `configuration`

- secondary artifacts (javadocs, classifiers, ...)

It does NOT include metadata of those artifacts (pom files,

ivy files, Gradle Module metadata).

It isn't required to resolve any configuration to get this

behavior: the build will automatically process all resolvable

configurations and _try_ to resolve them automatically. All

artifacts resolved during this process are going to be automatically

downloaded (if not already). Then SHA-1 and SHA-512 checksums

are computed for all those artifacts.

The current format is an XML file planned to support more than

just artifacts: module metadata AND signature information is

planned.

See #11398

  1. … 32 more files in changeset.
Generate checksum file for dependency verification

This commit introduces the generation of a dependency

verification metadata file from the CLI. If the user

calls `--write-verification-metadata`, then an XML

file is generated (`gradle/verification-metadata.xml`).

This file will contain the checksums for all artifacts

required by a build, which includes:

- plugin artifacts

- jars and other artifacts requested via a `configuration`

- secondary artifacts (javadocs, classifiers, ...)

It does NOT include metadata of those artifacts (pom files,

ivy files, Gradle Module metadata).

It isn't required to resolve any configuration to get this

behavior: the build will automatically process all resolvable

configurations and _try_ to resolve them automatically. All

artifacts resolved during this process are going to be automatically

downloaded (if not already). Then SHA-1 and SHA-512 checksums

are computed for all those artifacts.

The current format is an XML file planned to support more than

just artifacts: module metadata AND signature information is

planned.

See #11398

  1. … 32 more files in changeset.
Generate checksum file for dependency verification

This commit introduces the generation of a dependency

verification metadata file from the CLI. If the user

calls `--write-verification-metadata`, then an XML

file is generated (`gradle/verification-metadata.xml`).

This file will contain the checksums for all artifacts

required by a build, which includes:

- plugin artifacts

- jars and other artifacts requested via a `configuration`

- secondary artifacts (javadocs, classifiers, ...)

It does NOT include metadata of those artifacts (pom files,

ivy files, Gradle Module metadata).

It isn't required to resolve any configuration to get this

behavior: the build will automatically process all resolvable

configurations and _try_ to resolve them automatically. All

artifacts resolved during this process are going to be automatically

downloaded (if not already). Then SHA-1 and SHA-512 checksums

are computed for all those artifacts.

The current format is an XML file planned to support more than

just artifacts: module metadata AND signature information is

planned.

See #11398

  1. … 32 more files in changeset.
Generate checksum file for dependency verification

This commit introduces the generation of a dependency

verification metadata file from the CLI. If the user

calls `--write-verification-metadata`, then an XML

file is generated (`gradle/verification-metadata.xml`).

This file will contain the checksums for all artifacts

required by a build, which includes:

- plugin artifacts

- jars and other artifacts requested via a `configuration`

- secondary artifacts (javadocs, classifiers, ...)

It does NOT include metadata of those artifacts (pom files,

ivy files, Gradle Module metadata).

It isn't required to resolve any configuration to get this

behavior: the build will automatically process all resolvable

configurations and _try_ to resolve them automatically. All

artifacts resolved during this process are going to be automatically

downloaded (if not already). Then SHA-1 and SHA-512 checksums

are computed for all those artifacts.

The current format is an XML file planned to support more than

just artifacts: module metadata AND signature information is

planned.

See #11398

  1. … 32 more files in changeset.
Generate checksum file for dependency verification

This commit introduces the generation of a dependency

verification metadata file from the CLI. If the user

calls `--write-verification-metadata`, then an XML

file is generated (`gradle/verification-metadata.xml`).

This file will contain the checksums for all artifacts

required by a build, which includes:

- plugin artifacts

- jars and other artifacts requested via a `configuration`

- secondary artifacts (javadocs, classifiers, ...)

It does NOT include metadata of those artifacts (pom files,

ivy files, Gradle Module metadata).

It isn't required to resolve any configuration to get this

behavior: the build will automatically process all resolvable

configurations and _try_ to resolve them automatically. All

artifacts resolved during this process are going to be automatically

downloaded (if not already). Then SHA-1 and SHA-512 checksums

are computed for all those artifacts.

The current format is an XML file planned to support more than

just artifacts: module metadata AND signature information is

planned.

See #11398

  1. … 32 more files in changeset.
Generate checksum file for dependency verification

This commit introduces the generation of a dependency

verification metadata file from the CLI. If the user

calls `--write-verification-metadata`, then an XML

file is generated (`gradle/verification-metadata.xml`).

This file will contain the checksums for all artifacts

required by a build, which includes:

- plugin artifacts

- jars and other artifacts requested via a `configuration`

- secondary artifacts (javadocs, classifiers, ...)

It does NOT include metadata of those artifacts (pom files,

ivy files, Gradle Module metadata).

It isn't required to resolve any configuration to get this

behavior: the build will automatically process all resolvable

configurations and _try_ to resolve them automatically. All

artifacts resolved during this process are going to be automatically

downloaded (if not already). Then SHA-1 and SHA-512 checksums

are computed for all those artifacts.

The current format is an XML file planned to support more than

just artifacts: module metadata AND signature information is

planned.

See #11398

  1. … 32 more files in changeset.
Add action to forcefully resolve all configurations

  1. … 7 more files in changeset.
Add action to forcefully resolve all configurations

  1. … 7 more files in changeset.
Add a `add-plugin` CLI option

This commit introduces a new CLI flag, `--add-plugin`, which allows adding a plugin to a build

directly from the command line. The main advantage of this is that there's no need to have a

build file to be able to download an apply a plugin.

There are different use cases for this, but mainly, this is about _bootstraping_ plugins.

For example, the vert.x team could publish a plugin which generates a templated Gradle build.

All the user would have to do would be something like:

`gradle --add-plugin com.vertx.bootstrap:1.5`

and then the plugin would take care of generating a build.

Another use case is to add diagnostics (build scans is an example of this but there's already

a built-in mechanism, --scan, to do this).

This spike is _compatible with included builds_, meaning that you can bootstrap with

a plugin currently in development using `--include-build`.

  1. … 3 more files in changeset.
Fix regression when deprecating search upward APIs

  1. … 9 more files in changeset.
Fix regression when deprecating search upward APIs

  1. … 11 more files in changeset.
Fix regression when deprecating search upward APIs

  1. … 12 more files in changeset.
Fix regression when deprecating search upward APIs

  1. … 8 more files in changeset.
Fix regression when deprecating search upward APIs

  1. … 9 more files in changeset.
Revert "Merge pull request #10795 from gradle/lacasseio/deprecate-methods-on-start-parameter"

This reverts commit 40cb80789fed1f36e5501d9e8ac35fcb290c6b76, reversing

changes made to f6c349254943c709e33dd409729174f5adf9f6ce.

  1. … 9 more files in changeset.