Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
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.
Use default values for TAPI provider interfaces

  1. … 1 more file in changeset.
Use default values for TAPI provider interfaces

  1. … 1 more file in changeset.
Use default values for TAPI provider interfaces

  1. … 2 more files in changeset.
Use default values for TAPI provider interfaces

  1. … 2 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.
Move InetAddressFactory to :base-services and work around JDK bug

See https://bugs.openjdk.java.net/browse/JDK-8143378

  1. … 25 more files in changeset.
Move InetAddressFactory to :base-services and work around JDK bug

See https://bugs.openjdk.java.net/browse/JDK-8143378

  1. … 25 more files in changeset.
Move InetAddressFactory to :base-services and work around JDK bug

See https://bugs.openjdk.java.net/browse/JDK-8143378

  1. … 25 more files in changeset.
Add new methods to execute tests in a single task

  1. … 5 more files in changeset.
Add new methods to execute tests in a single task

  1. … 5 more files in changeset.
Prototype new TestLauncher.withTests() API method

  1. … 5 more files in changeset.
Prototype new TestLauncher.withTests() API method

  1. … 5 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.
Revert "Revert "Merge branch 'release'""

This reverts commit 67b8bb8f18f854f45a2f5ec52cc9c8a25981e2f2.

This restores the merge attempt from earlier.

  1. … 61 more files in changeset.
Revert "Merge branch 'release'"

This reverts commit c7fdc455dcb9a8016af0ae9bc8b4c43fde1e2d06, reversing

changes made to 9f70d52b74dbc8c71381781b6c155474031b3cf8.

The changes need a wrapper as there are API changes. Reverting for now.

  1. … 61 more files in changeset.
Reduce the amount of logging that is periodically emitted by an idle daemon

  1. … 2 more files in changeset.
Use single event instead of start-finish pair to publish test output

  1. … 12 more files in changeset.
Use single event instead of start-finish pair to publish test output

  1. … 12 more files in changeset.
Use single event instead of start-finish pair to publish test output

  1. … 12 more files in changeset.
Use single event instead of start-finish pair to publish test output

  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. … 8 more files in changeset.