Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Compute checksums concurrently

This commit reworks how checksums are computed by computing

them concurrently between projects. Checksums are computed

in parallel, however we preserve write order. This involves

a bit more memory usage but it proves to be faster.

  1. … 3 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.
Track 'changing' and 'client module' information for override metadata

Although these are edge cases, it leads to more consistency and makes

the behavior less dependent on order which may change unexpectedly

through internal optimisations.

    • -3
    • +6
    ./DefaultComponentOverrideMetadata.java
  1. … 6 more files in changeset.
Track 'changing' and 'client module' information for override metadata

Although these are edge cases, it leads to more consistency and makes

the behavior less dependent on order which may change unexpectedly

through internal optimisations.

    • -3
    • +6
    ./DefaultComponentOverrideMetadata.java
  1. … 6 more files in changeset.
Track 'changing' and 'client module' information for override metadata

Although these are edge cases, it leads to more consistency and makes

the behavior less dependent on order which may change unexpectedly

through internal optimisations.

    • -3
    • +6
    ./DefaultComponentOverrideMetadata.java
  1. … 6 more files in changeset.
Track 'changing' and 'client module' information for override metadata

Although these are edge cases, it leads to more consistency and makes

the behavior less dependent on order which may change unexpectedly

through internal optimisations.

    • -3
    • +6
    ./DefaultComponentOverrideMetadata.java
  1. … 6 more files in changeset.
Track 'changing' and 'client module' information for override metadata

Although these are edge cases, it leads to more consistency and makes

the behavior less dependent on order which may change unexpectedly

through internal optimisations.

    • -3
    • +6
    ./DefaultComponentOverrideMetadata.java
  1. … 7 more files in changeset.
Track 'changing' and 'client module' information for override metadata

Although these are edge cases, it leads to more consistency and makes

the behavior less dependent on order which may change unexpectedly

through internal optimisations.

    • -3
    • +6
    ./DefaultComponentOverrideMetadata.java
  1. … 4 more files in changeset.
Use the first found dependency artifact for override metadata

Later in the resolution, we already combine all artifacts defined

as 'dependency artifacts' on incoming edges.

If a component does not have metadata, we need at least information

about one artifact early when we look for an artifact (instead of a

metadata file).

    • -6
    • +6
    ./DefaultComponentOverrideMetadata.java
  1. … 9 more files in changeset.
Use the first found dependency artifact for override metadata

Later in the resolution, we already combine all artifacts defined

as 'dependency artifacts' on incoming edges.

If a component does not have metadata, we need at least information

about one artifact early when we look for an artifact (instead of a

metadata file).

    • -6
    • +6
    ./DefaultComponentOverrideMetadata.java
  1. … 9 more files in changeset.
Use the first found dependency artifact for override metadata

Later in the resolution, we already combine all artifacts defined

as 'dependency artifacts' on incoming edges.

If a component does not have metadata, we need at least information

about one artifact early when we look for an artifact (instead of a

metadata file).

    • -6
    • +6
    ./DefaultComponentOverrideMetadata.java
  1. … 9 more files in changeset.
Use the first found dependency artifact for override metadata

Later in the resolution, we already combine all artifacts defined

as 'dependency artifacts' on incoming edges.

If a component does not have metadata, we need at least information

about one artifact early when we look for an artifact (instead of a

metadata file).

    • -6
    • +6
    ./DefaultComponentOverrideMetadata.java
  1. … 9 more files in changeset.
Reuse one object for empty ComponentOverrideMetadata

    • -2
    • +4
    ./DefaultComponentOverrideMetadata.java
  1. … 3 more files in changeset.
Reuse one object for empty ComponentOverrideMetadata

    • -2
    • +4
    ./DefaultComponentOverrideMetadata.java
  1. … 3 more files in changeset.
Reuse one object for empty ComponentOverrideMetadata

    • -2
    • +4
    ./DefaultComponentOverrideMetadata.java
  1. … 3 more files in changeset.
Reuse one object for empty ComponentOverrideMetadata

    • -2
    • +4
    ./DefaultComponentOverrideMetadata.java
  1. … 3 more files in changeset.
Avoid copying an already immutable list

    • -1
    • +1
    ./LocalComponentDependencyMetadata.java
Avoid copying an already immutable list

    • -1
    • +1
    ./LocalComponentDependencyMetadata.java
Avoid copying an already immutable list

    • -1
    • +1
    ./LocalComponentDependencyMetadata.java
Avoid copying an already immutable list

    • -1
    • +1
    ./LocalComponentDependencyMetadata.java
Avoid copying an already immutable list

    • -1
    • +1
    ./LocalComponentDependencyMetadata.java
Use the dependency artifacts of all selectors for override metadata

Later in the resolution, we already combine all artifacts defined

as 'dependency artifacts' on incoming edges.

If a component does not have metadata, we also need to consider all

this information early when we look for an artifact (instead of a

metadata file).

    • -2
    • +2
    ./DefaultComponentOverrideMetadata.java
  1. … 9 more files in changeset.
Reuse one object for empty ComponentOverrideMetadata

    • -2
    • +4
    ./DefaultComponentOverrideMetadata.java
  1. … 3 more files in changeset.
Revert "Revert "Merge branch 'release'""

This reverts commit 67b8bb8f18f854f45a2f5ec52cc9c8a25981e2f2.

This restores the merge attempt from earlier.

  1. … 66 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. … 66 more files in changeset.
Fix AttributeConfigurationSelector to return the filtered result 2/2

Same as 3255f1d for different code path.

  1. … 1 more file in changeset.