Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
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.
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. … 8 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.
Introduce module metadata verification

This commit introduces verification of metadata files.

For this, another refactoring of the `ModuleSource` concept

was required. Ironically, before this commit, `ModuleSource`

used to be available for serialization in the module metadata

serializer. However, they weren't used in practice, because

all the required data could be reconstructed from the caches.

In particular, there was this "contentHash" which, because

not properly serialized, was actually set as a field on the

component resolve metadata itself, instead of being part

of the module source.

Now, this commit reintroduces serialization of module sources

but takes a different approach by splitting the module sources

in two distinct categories:

- module sources which can be reconstructed from known data,

such as the repository name and repository url

- module sources which have to be serialized alongside component

metadata, because they can't be reconstructed from sources

The latter category includes this "contentHash", serialized with

the descriptor hash module source. It also includes the information

about _which_ actual descriptor file was used to generate the

binary module descriptor (e.g, the source POM, Ivy or module

metadata file). This information does _not_ belong to the module

component resolve metadata itself, so it belongs to its sources.

For this purpose, serialization of module sources has been updated

so that instead of using Java serialization, module sources need

to provide a custom serializer, called a Codec. Those codecs are

uniquely identified by an id which is just an integer. This is

done for performance optimization, in order to avoid to serialize

the name of the codec and have to load it dynamically. Instead,

Gradle knows about the full set of serializers (and there's no

way for a user to add more because in any case it would require

an update of the module metadata store format).

This makes it much more efficient to serialize module sources

(because we can now have an optimized encoder), but it also

permits reconstructing module sources from incomplete information.

In particular, the module source which describes the file from

which a component resolve metadata was sourced contains a link

to the actual file in the local artifact store. However, in order

to be relocatable, we _don't_ want this file path to be stored

in the metadata cache. This means that instead of storing the

path, we actually store the artifact identifier and the hash

of the descriptor so that we can, when loaded from cache, find

its location back.

Currently, metadata verification is enabled for all components.

It's not possible to disable verification of metadata.

    • -6
    • +16
    ./resolve/verification/DependencyVerificationIntegrityCheckIntegTest.groovy
    • -3
    • +189
    ./resolve/verification/DependencyVerificationWritingIntegTest.groovy
  1. … 38 more files in changeset.
Introduce module metadata verification

This commit introduces verification of metadata files.

For this, another refactoring of the `ModuleSource` concept

was required. Ironically, before this commit, `ModuleSource`

used to be available for serialization in the module metadata

serializer. However, they weren't used in practice, because

all the required data could be reconstructed from the caches.

In particular, there was this "contentHash" which, because

not properly serialized, was actually set as a field on the

component resolve metadata itself, instead of being part

of the module source.

Now, this commit reintroduces serialization of module sources

but takes a different approach by splitting the module sources

in two distinct categories:

- module sources which can be reconstructed from known data,

such as the repository name and repository url

- module sources which have to be serialized alongside component

metadata, because they can't be reconstructed from sources

The latter category includes this "contentHash", serialized with

the descriptor hash module source. It also includes the information

about _which_ actual descriptor file was used to generate the

binary module descriptor (e.g, the source POM, Ivy or module

metadata file). This information does _not_ belong to the module

component resolve metadata itself, so it belongs to its sources.

For this purpose, serialization of module sources has been updated

so that instead of using Java serialization, module sources need

to provide a custom serializer, called a Codec. Those codecs are

uniquely identified by an id which is just an integer. This is

done for performance optimization, in order to avoid to serialize

the name of the codec and have to load it dynamically. Instead,

Gradle knows about the full set of serializers (and there's no

way for a user to add more because in any case it would require

an update of the module metadata store format).

This makes it much more efficient to serialize module sources

(because we can now have an optimized encoder), but it also

permits reconstructing module sources from incomplete information.

In particular, the module source which describes the file from

which a component resolve metadata was sourced contains a link

to the actual file in the local artifact store. However, in order

to be relocatable, we _don't_ want this file path to be stored

in the metadata cache. This means that instead of storing the

path, we actually store the artifact identifier and the hash

of the descriptor so that we can, when loaded from cache, find

its location back.

Currently, metadata verification is enabled for all components.

It's not possible to disable verification of metadata.

    • -6
    • +16
    ./resolve/verification/DependencyVerificationIntegrityCheckIntegTest.groovy
    • -0
    • +52
    ./resolve/verification/DependencyVerificationWritingIntegTest.groovy
  1. … 37 more files in changeset.
Introduce module metadata verification

This commit introduces verification of metadata files.

For this, another refactoring of the `ModuleSource` concept

was required. Ironically, before this commit, `ModuleSource`

used to be available for serialization in the module metadata

serializer. However, they weren't used in practice, because

all the required data could be reconstructed from the caches.

In particular, there was this "contentHash" which, because

not properly serialized, was actually set as a field on the

component resolve metadata itself, instead of being part

of the module source.

Now, this commit reintroduces serialization of module sources

but takes a different approach by splitting the module sources

in two distinct categories:

- module sources which can be reconstructed from known data,

such as the repository name and repository url

- module sources which have to be serialized alongside component

metadata, because they can't be reconstructed from sources

The latter category includes this "contentHash", serialized with

the descriptor hash module source. It also includes the information

about _which_ actual descriptor file was used to generate the

binary module descriptor (e.g, the source POM, Ivy or module

metadata file). This information does _not_ belong to the module

component resolve metadata itself, so it belongs to its sources.

For this purpose, serialization of module sources has been updated

so that instead of using Java serialization, module sources need

to provide a custom serializer, called a Codec. Those codecs are

uniquely identified by an id which is just an integer. This is

done for performance optimization, in order to avoid to serialize

the name of the codec and have to load it dynamically. Instead,

Gradle knows about the full set of serializers (and there's no

way for a user to add more because in any case it would require

an update of the module metadata store format).

This makes it much more efficient to serialize module sources

(because we can now have an optimized encoder), but it also

permits reconstructing module sources from incomplete information.

In particular, the module source which describes the file from

which a component resolve metadata was sourced contains a link

to the actual file in the local artifact store. However, in order

to be relocatable, we _don't_ want this file path to be stored

in the metadata cache. This means that instead of storing the

path, we actually store the artifact identifier and the hash

of the descriptor so that we can, when loaded from cache, find

its location back.

Currently, metadata verification is enabled for all components.

It's not possible to disable verification of metadata.

    • -6
    • +16
    ./resolve/verification/DependencyVerificationIntegrityCheckIntegTest.groovy
    • -3
    • +189
    ./resolve/verification/DependencyVerificationWritingIntegTest.groovy
  1. … 38 more files in changeset.
Introduce module metadata verification

This commit introduces verification of metadata files.

For this, another refactoring of the `ModuleSource` concept

was required. Ironically, before this commit, `ModuleSource`

used to be available for serialization in the module metadata

serializer. However, they weren't used in practice, because

all the required data could be reconstructed from the caches.

In particular, there was this "contentHash" which, because

not properly serialized, was actually set as a field on the

component resolve metadata itself, instead of being part

of the module source.

Now, this commit reintroduces serialization of module sources

but takes a different approach by splitting the module sources

in two distinct categories:

- module sources which can be reconstructed from known data,

such as the repository name and repository url

- module sources which have to be serialized alongside component

metadata, because they can't be reconstructed from sources

The latter category includes this "contentHash", serialized with

the descriptor hash module source. It also includes the information

about _which_ actual descriptor file was used to generate the

binary module descriptor (e.g, the source POM, Ivy or module

metadata file). This information does _not_ belong to the module

component resolve metadata itself, so it belongs to its sources.

For this purpose, serialization of module sources has been updated

so that instead of using Java serialization, module sources need

to provide a custom serializer, called a Codec. Those codecs are

uniquely identified by an id which is just an integer. This is

done for performance optimization, in order to avoid to serialize

the name of the codec and have to load it dynamically. Instead,

Gradle knows about the full set of serializers (and there's no

way for a user to add more because in any case it would require

an update of the module metadata store format).

This makes it much more efficient to serialize module sources

(because we can now have an optimized encoder), but it also

permits reconstructing module sources from incomplete information.

In particular, the module source which describes the file from

which a component resolve metadata was sourced contains a link

to the actual file in the local artifact store. However, in order

to be relocatable, we _don't_ want this file path to be stored

in the metadata cache. This means that instead of storing the

path, we actually store the artifact identifier and the hash

of the descriptor so that we can, when loaded from cache, find

its location back.

Currently, metadata verification is enabled for all components.

It's not possible to disable verification of metadata.

    • -6
    • +16
    ./resolve/verification/DependencyVerificationIntegrityCheckIntegTest.groovy
    • -3
    • +189
    ./resolve/verification/DependencyVerificationWritingIntegTest.groovy
  1. … 38 more files in changeset.
Ignore changing modules for dependency verification

    • -0
    • +25
    ./resolve/verification/DependencyVerificationIntegrityCheckIntegTest.groovy
    • -0
    • +23
    ./resolve/verification/DependencyVerificationWritingIntegTest.groovy
  1. … 1 more file in changeset.
Ignore changing modules for dependency verification

    • -0
    • +25
    ./resolve/verification/DependencyVerificationIntegrityCheckIntegTest.groovy
    • -0
    • +23
    ./resolve/verification/DependencyVerificationWritingIntegTest.groovy
  1. … 1 more file in changeset.
Add tests for rewiring compile task dependencies

This also updates existing tests to use the new API.

    • -1
    • +1
    ./resolve/attributes/VariantAwareResolutionWithConfigurationAttributesIntegrationTest.groovy
  1. … 15 more files in changeset.
Add tests for rewiring compile task dependencies

This also updates existing tests to use the new API.

    • -1
    • +1
    ./resolve/attributes/VariantAwareResolutionWithConfigurationAttributesIntegrationTest.groovy
  1. … 15 more files in changeset.
Add tests for rewiring compile task dependencies

This also updates existing tests to use the new API.

    • -1
    • +1
    ./resolve/attributes/VariantAwareResolutionWithConfigurationAttributesIntegrationTest.groovy
  1. … 15 more files in changeset.
Add tests for rewiring compile task dependencies

This also updates existing tests to use the new API.

    • -1
    • +1
    ./resolve/attributes/VariantAwareResolutionWithConfigurationAttributesIntegrationTest.groovy
  1. … 15 more files in changeset.
Add tests for rewiring compile task dependencies

This also updates existing tests to use the new API.

    • -1
    • +1
    ./resolve/attributes/VariantAwareResolutionWithConfigurationAttributesIntegrationTest.groovy
  1. … 15 more files in changeset.
Add tests for rewiring compile task dependencies

This also updates existing tests to use the new API.

    • -1
    • +1
    ./resolve/attributes/VariantAwareResolutionWithConfigurationAttributesIntegrationTest.groovy
  1. … 15 more files in changeset.
Add tests for rewiring compile task dependencies

This also updates existing tests to use the new API.

    • -1
    • +1
    ./resolve/attributes/VariantAwareResolutionWithConfigurationAttributesIntegrationTest.groovy
  1. … 15 more files in changeset.
Add tests for rewiring compile task dependencies

This also updates existing tests to use the new API.

    • -1
    • +1
    ./resolve/attributes/VariantAwareResolutionWithConfigurationAttributesIntegrationTest.groovy
  1. … 15 more files in changeset.
Improve error for non resolvable configurations

When attempting to resolve a configuration that is canBeResolved=false,

the error now mentions it is a dependency configuration and that

resolution "on its own" is invalid.

    • -3
    • +3
    ./resolve/api/ConfigurationRoleIntegrationTest.groovy
  1. … 3 more files in changeset.