Clone Tools
  • last updated a few minutes ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Avoid eager creation of `ResolveIvyFactory`

The `ResolveIvyFactory` instance was created too eagerly. In general,

this isn't a problem because most builds will eventually resolve

dependencies. But there are cases, like when calling `help`, when this

is not the case.

The previous code was assuming that a factory would always be created,

and by side effect moved the creation of the factory to an earlier

phase during build initialization, triggering the creation of the file

access journal.

This is no longer the case: we only create the dependency verification

parameter override eagerly, and configure the build to shut it down

at the end of the build.

  1. … 4 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. … 30 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. … 30 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. … 30 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. … 30 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. … 30 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. … 30 more files in changeset.
Desugar producer attribute if the requesting attribute is desugared (#11372)

This can be the case if an attribute on a dependency is published

and the resolved target of the dependency is a local project.

For example, a published platform dependency to a local java-platform

project.

We support 'Named' and 'Enum' for desugaring as that are the only

non-primitve types we currently allow to be published in Gradle

Module Metadata.

  1. … 3 more files in changeset.
Desugar producer attribute if the requesting attribute is desugared

This can be the case if a attribute on a dependency is published

and the resolved target of the dependency is a local project.

For example, a published platform dependency to a local java-platform

project.

  1. … 3 more files in changeset.
Desugar producer attribute if the requesting attribute is desugared

This can be the case if a attribute on a dependency is published

and the resolved target of the dependency is a local project.

For example, a published platform dependency to a local java-platform

project.

We support 'Named' and 'Enum' for desugaring as that are the only

non-primimitve types we currently allow to be published in Gradle

Module Metadata.

  1. … 3 more files in changeset.
Desugar producer attribute if the requesting attribute is desugared

This can be the case if a attribute on a dependency is published

and the resolved target of the dependency is a local project.

For example, a published platform dependency to a local java-platform

project.

  1. … 3 more files in changeset.
Desugar producer attribute if the requesting attribute is desugared

This can be the case if a attribute on a dependency is published

and the resolved target of the dependency is a local project.

For example, a published platform dependency to a local java-platform

project.

We support 'Named' and 'Enum' for desugaring as that are the only

non-primimitve types we currently allow to be published in Gradle

Module Metadata.

  1. … 3 more files in changeset.
Make query methods for deprecation state of core configurations public

This is to allow plugin authors to make use of this information.

The methods to actually deprecate configurations stay internal,

as they are bound to the deprecation mechanism of Gradle core.

And thus they may only be used for configurations of Gradle's core

plugins.

  1. … 12 more files in changeset.
Make query methods for deprecation state of core configurations public

This is to allow plugin authors to make use of this information.

The methods to actually deprecate configurations stay internal,

as they are bound to the deprecation mechanism of Gradle core.

And thus they may only be used for configurations of Gradle's core

plugins.

  1. … 12 more files in changeset.
Tweak messages for previous commit, fixes.

  1. … 11 more files in changeset.
Add `BuildServiceParameters.None` marker type that is used to indicate that a build service does not take any parameters, to match the pattern used in other places.

Extract some validation logic from several places so it can be reused in the places where parameterized isolated objects, such as artifact transforms or build services, are registered.

  1. … 35 more files in changeset.
Add `BuildServiceParameters.None` marker type that is used to indicate that a build service does not take any parameters, to match the pattern used in other places.

Extract some validation logic from several places so it can be reused in the places where parameterized isolated objects, such as artifact transforms or build services, are registered.

  1. … 35 more files in changeset.
Handle serialization for shadowed capabilities in the GMM case (#11179)

This is now done in the same way as it is done in the

AbstractRealisedModuleResolveMetadataSerializationHelper

for cases without GMM

Follow up to: #11118

  1. … 4 more files in changeset.
Handle serialization for shadowed capabilities in the GMM case

This is now done in the same way as it is done in the

AbstractRealisedModuleResolveMetadataSerializationHelper

for cases without GMM

Follow up to: #11118

  1. … 4 more files in changeset.
Implement lenient mode for locking

In lenient mode, lock entries are `requires` and not `strictly` and

there is no validation after resolution. This allows deviations from the

lock state.

  1. … 8 more files in changeset.
Implement lenient mode for locking

In lenient mode, lock entries are `requires` and not `strictly` and

there is no validation after resolution. This allows deviations from the

lock state.

  1. … 8 more files in changeset.
Implement lenient mode for locking

In lenient mode, lock entries are `requires` and not `strictly` and

there is no validation after resolution. This allows deviations from the

lock state.

  1. … 8 more files in changeset.
Implement lenient mode for locking

In lenient mode, lock entries are `requires` and not `strictly` and

there is no validation after resolution. This allows deviations from the

lock state.

  1. … 8 more files in changeset.
There can be multiple enforced platform variants for Gradle metadata

Follow up to: #11118

  1. … 3 more files in changeset.
There can be multiple enforced platform variants for Gradle metadata

Follow up to: #11118

  1. … 3 more files in changeset.
Increase cache layout version

  1. … 1 more file in changeset.
Increase cache layout version

  1. … 1 more file in changeset.
Increase cache layout version

  1. … 1 more file in changeset.
Remove `platform` dsl from constraint handler

These shortcuts define details of a dependency like attributes,

requested capabilities and 'endorse strict' status. These things

can not be defined on constraints. So these methods only cause

inconsistent behavior.

One can use constraints in combination with platforms like this to

control platform versions:

dependencies {

api platform("org:platform")

constraints {

api "org:platform:1.0"

}

}

  1. … 11 more files in changeset.
Remove `platform` dsl from constraint handler

These shortcuts define details of a dependency like attributes,

requested capabilities and 'endorse strict' status. These things

can not be defined on constraints. So these methods only cause

inconsistent behavior.

One can use constraints in combination with platforms like this to

control platform versions:

dependencies {

api platform("org:platform")

constraints {

api "org:platform:1.0"

}

}

  1. … 9 more files in changeset.