Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Recompute selected component when removing selector

Previously, once a component was selected, removing a selector would not

change the resolution result, potentially keeping a selection that no

longer applied.

Now upon removal of a selector, the selected component may be updated.

In order to prevent infinite loops in some cases, the recompute on

removal only happens once per SelectorState instance.

Fixes #6567

    • -11
    • +35
    ./resolve/VersionConflictResolutionIntegrationTest.groovy
  1. … 7 more files in changeset.
Recompute selected component when removing selector

Previously, once a component was selected, removing a selector would not

change the resolution result, potentially keeping a selection that no

longer applied.

Now upon removal of a selector, the selected component may be updated.

In order to prevent infinite loops in some cases, the recompute on

removal only happens once per SelectorState instance.

Fixes #6567

    • -11
    • +35
    ./resolve/VersionConflictResolutionIntegrationTest.groovy
  1. … 7 more files in changeset.
Recompute selected component when removing selector

Previously, once a component was selected, removing a selector would not

change the resolution result, potentially keeping a selection that no

longer applied.

Now upon removal of a selector, the selected component may be updated.

In order to prevent infinite loops in some cases, the recompute on

removal only happens once per SelectorState instance.

Fixes #6567

    • -11
    • +35
    ./resolve/VersionConflictResolutionIntegrationTest.groovy
  1. … 7 more files in changeset.
Recompute selected component when removing selector

Previously, once a component was selected, removing a selector would not

change the resolution result, potentially keeping a selection that no

longer applied.

Now upon removal of a selector, the selected component may be updated.

In order to prevent infinite loops in some cases, the recompute on

removal only happens once per SelectorState instance.

Fixes #6567

    • -11
    • +34
    ./resolve/VersionConflictResolutionIntegrationTest.groovy
  1. … 7 more files in changeset.
Recompute selected component when removing selector

Previously, once a component was selected, removing a selector would not

change the resolution result, potentially keeping a selection that no

longer applied.

Now upon removal of a selector, the selected component may be updated.

In order to prevent infinite loops in some cases, the recompute on

removal only happens once per SelectorState instance.

Fixes #6567

    • -11
    • +35
    ./resolve/VersionConflictResolutionIntegrationTest.groovy
  1. … 7 more files in changeset.
Recompute selected component when removing selector

Previously, once a component was selected, removing a selector would not

change the resolution result, potentially keeping a selection that no

longer applied.

Now upon removal of a selector, the selected component may be updated.

In order to prevent infinite loops in some cases, the recompute on

removal only happens once per SelectorState instance.

Fixes #6567

    • -11
    • +35
    ./resolve/VersionConflictResolutionIntegrationTest.groovy
  1. … 7 more files in changeset.
Add lenient version of ComponentMetadataDetails.addVariant()

    • -10
    • +90
    ./resolve/rules/VariantFilesMetadataRulesIntegrationTest.groovy
  1. … 10 more files in changeset.
Introduce a checksum file cache service

This service is responsible for caching the checksums computed from

local file system. Because it's also used for dependency verification

writing and checking, this cache uses the existing infrastructure which

makes sure that if a file is updated locally, we expire the entry in

the cache.

This is done because there are lots of places in the code where we

used the legacy `HashUtil` class, which has no caching whatsoever.

It's, however, quite common to have a build which generates sha1

checksums multiple times for the same file. For example, during

publication.

    • -6
    • +9
    ./resolve/caching/CachedDependencyResolutionIntegrationTest.groovy
    • -3
    • +3
    ./resolve/verification/DependencyVerificationWritingIntegTest.groovy
  1. … 101 more files in changeset.
Introduce a checksum file cache service

This service is responsible for caching the checksums computed from

local file system. Because it's also used for dependency verification

writing and checking, this cache uses the existing infrastructure which

makes sure that if a file is updated locally, we expire the entry in

the cache.

This is done because there are lots of places in the code where we

used the legacy `HashUtil` class, which has no caching whatsoever.

It's, however, quite common to have a build which generates sha1

checksums multiple times for the same file. For example, during

publication.

    • -6
    • +9
    ./resolve/caching/CachedDependencyResolutionIntegrationTest.groovy
    • -3
    • +3
    ./resolve/verification/DependencyVerificationWritingIntegTest.groovy
  1. … 101 more files in changeset.
Introduce a checksum file cache service

This service is responsible for caching the checksums computed from

local file system. Because it's also used for dependency verification

writing and checking, this cache uses the existing infrastructure which

makes sure that if a file is updated locally, we expire the entry in

the cache.

This is done because there are lots of places in the code where we

used the legacy `HashUtil` class, which has no caching whatsoever.

It's, however, quite common to have a build which generates sha1

checksums multiple times for the same file. For example, during

publication.

    • -6
    • +9
    ./resolve/caching/CachedDependencyResolutionIntegrationTest.groovy
    • -3
    • +3
    ./resolve/verification/DependencyVerificationWritingIntegTest.groovy
  1. … 101 more files in changeset.
Introduce a checksum file cache service

This service is responsible for caching the checksums computed from

local file system. Because it's also used for dependency verification

writing and checking, this cache uses the existing infrastructure which

makes sure that if a file is updated locally, we expire the entry in

the cache.

This is done because there are lots of places in the code where we

used the legacy `HashUtil` class, which has no caching whatsoever.

It's, however, quite common to have a build which generates sha1

checksums multiple times for the same file. For example, during

publication.

    • -6
    • +9
    ./resolve/caching/CachedDependencyResolutionIntegrationTest.groovy
    • -1
    • +1
    ./resolve/verification/DependencyVerificationIntegrityCheckIntegTest.groovy
    • -10
    • +10
    ./resolve/verification/DependencyVerificationWritingIntegTest.groovy
  1. … 101 more files in changeset.
Add some debug logging

    • -0
    • +1
    ./resolve/rules/ComponentMetadataRulesCachingIntegrationTest.groovy
  1. … 2 more files in changeset.
Add logging of the test path

This is done in order to debug checksums failing on CI

    • -1
    • +2
    ./resolve/verification/AbstractDependencyVerificationIntegTest.groovy
Bump metadata format

    • -7
    • +7
    ./resolve/rules/ComponentMetadataRulesCachingIntegrationTest.groovy
  1. … 2 more files in changeset.
Always serialize module sources

Module sources were only serialized in the cache metadata entry.

In practice, they belong to the module metadata, so they are now

properly serialized as part of it. This fixes the "force realize"

tests.

    • -7
    • +8
    ./resolve/rules/ComponentMetadataRulesCachingIntegrationTest.groovy
    • -1
    • +2
    ./resolve/verification/AbstractDependencyVerificationIntegTest.groovy
  1. … 17 more files in changeset.
Always serialize module sources

Module sources were only serialized in the cache metadata entry.

In practice, they belong to the module metadata, so they are now

properly serialized as part of it. This fixes the "force realize"

tests.

    • -7
    • +8
    ./resolve/rules/ComponentMetadataRulesCachingIntegrationTest.groovy
    • -1
    • +2
    ./resolve/verification/AbstractDependencyVerificationIntegTest.groovy
  1. … 17 more files in changeset.
Always serialize module sources

Module sources were only serialized in the cache metadata entry.

In practice, they belong to the module metadata, so they are now

properly serialized as part of it. This fixes the "force realize"

tests.

    • -7
    • +8
    ./resolve/rules/ComponentMetadataRulesCachingIntegrationTest.groovy
    • -1
    • +2
    ./resolve/verification/AbstractDependencyVerificationIntegTest.groovy
  1. … 17 more files in changeset.
Add more test coverage for deleted artifacts

    • -0
    • +100
    ./resolve/verification/DependencyVerificationIntegrityCheckIntegTest.groovy
  1. … 5 more files in changeset.
Add more test coverage for deleted artifacts

    • -0
    • +100
    ./resolve/verification/DependencyVerificationIntegrityCheckIntegTest.groovy
  1. … 5 more files in changeset.
Add more test coverage for deleted artifacts

    • -0
    • +100
    ./resolve/verification/DependencyVerificationIntegrityCheckIntegTest.groovy
  1. … 2 more files in changeset.
Track composition of Maven module metadata

The binary representation of a Maven POM was only tracking the

POM file itself as the source. However, a POM can reference

parent POMs which also participate in resolution. This commit

changes the `ModuleSources` so that we can query more than one

module source of a specific type, allowing us to store more

than a single module source for a single file.

    • -3
    • +2
    ./resolve/verification/DependencyVerificationWritingIntegTest.groovy
  1. … 4 more files in changeset.
Track composition of Maven module metadata

The binary representation of a Maven POM was only tracking the

POM file itself as the source. However, a POM can reference

parent POMs which also participate in resolution. This commit

changes the `ModuleSources` so that we can query more than one

module source of a specific type, allowing us to store more

than a single module source for a single file.

    • -3
    • +2
    ./resolve/verification/DependencyVerificationWritingIntegTest.groovy
  1. … 4 more files in changeset.
Track composition of Maven module metadata

The binary representation of a Maven POM was only tracking the

POM file itself as the source. However, a POM can reference

parent POMs which also participate in resolution. This commit

changes the `ModuleSources` so that we can query more than one

module source of a specific type, allowing us to store more

than a single module source for a single file.

    • -3
    • +2
    ./resolve/verification/DependencyVerificationWritingIntegTest.groovy
  1. … 4 more files in changeset.
Normalize line endings for generated metadata files

The test fixtures do not normalize line endings, which causes

unexpected build failures under Windows.

    • -2
    • +2
    ./resolve/verification/DependencyVerificationIntegrityCheckIntegTest.groovy
  1. … 2 more files in changeset.
Fix fixtures for Windows

The test fixtures do not normalize line endings, which causes

unexpected build failures under Windows.

There's also a date format used for timestamps which may

return a different value under Windows depending on the

current timezone and locale.

    • -9
    • +9
    ./resolve/verification/DependencyVerificationIntegrityCheckIntegTest.groovy
  1. … 3 more files in changeset.
Fix fixtures for Windows

The test fixtures do not normalize line endings, which causes

unexpected build failures under Windows.

There's also a date format used for timestamps which may

return a different value under Windows depending on the

current timezone and locale.

    • -9
    • +9
    ./resolve/verification/DependencyVerificationIntegrityCheckIntegTest.groovy
    • -22
    • +22
    ./resolve/verification/DependencyVerificationWritingIntegTest.groovy
  1. … 3 more files in changeset.
Attempt to reproduce

    • -8
    • +11
    ./resolve/transform/ArtifactTransformParallelIntegrationTest.groovy
Bump layout format

    • -9
    • +9
    ./resolve/verification/DependencyVerificationIntegrityCheckIntegTest.groovy
    • -22
    • +22
    ./resolve/verification/DependencyVerificationWritingIntegTest.groovy
  1. … 5 more files in changeset.
Bump layout format

    • -9
    • +9
    ./resolve/verification/DependencyVerificationIntegrityCheckIntegTest.groovy
    • -22
    • +22
    ./resolve/verification/DependencyVerificationWritingIntegTest.groovy
  1. … 5 more files in changeset.
Use file names instea of Ivy artifact names for comparison

This commit reworks the generation of verification file and

verification itself in order to use the file name instead of

the Ivy artifact name. This is done because in case of Gradle

module metadata, the file name of an artifact is not necessarily

directly bound to the module name and causes comparison issues.

    • -32
    • +35
    ./resolve/verification/DependencyVerificationWritingIntegTest.groovy
  1. … 10 more files in changeset.