Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
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.

  1. … 100 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.

  1. … 100 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.

  1. … 100 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.

  1. … 101 more files in changeset.
Refactor `ModuleSource`

The `ModuleSource` concept was a bit messy. It was designed in order

to be able to store the origin of an artifact. Over time, it evolved

into storing more information, like snapshot timestamps, repositories

or content hash.

The code was convoluted because each part of the code was expecting

some kind of module source, but because of delegation, it wasn't

really possible to add/mix more sources.

This commit refactors this concept into a `ModuleSources` concept

which allows storing more information about a module source, in

a safe and consistent manner. No more wrapping/unwrapping, and each

code requiring a specific type of module source can query for it.

  1. … 64 more files in changeset.
Refactor `ModuleSource`

The `ModuleSource` concept was a bit messy. It was designed in order

to be able to store the origin of an artifact. Over time, it evolved

into storing more information, like snapshot timestamps, repositories

or content hash.

The code was convoluted because each part of the code was expecting

some kind of module source, but because of delegation, it wasn't

really possible to add/mix more sources.

This commit refactors this concept into a `ModuleSources` concept

which allows storing more information about a module source, in

a safe and consistent manner. No more wrapping/unwrapping, and each

code requiring a specific type of module source can query for it.

  1. … 62 more files in changeset.
Refactor `ModuleSource`

The `ModuleSource` concept was a bit messy. It was designed in order

to be able to store the origin of an artifact. Over time, it evolved

into storing more information, like snapshot timestamps, repositories

or content hash.

The code was convoluted because each part of the code was expecting

some kind of module source, but because of delegation, it wasn't

really possible to add/mix more sources.

This commit refactors this concept into a `ModuleSources` concept

which allows storing more information about a module source, in

a safe and consistent manner. No more wrapping/unwrapping, and each

code requiring a specific type of module source can query for it.

  1. … 64 more files in changeset.
Refactor `ModuleSource`

The `ModuleSource` concept was a bit messy. It was designed in order

to be able to store the origin of an artifact. Over time, it evolved

into storing more information, like snapshot timestamps, repositories

or content hash.

The code was convoluted because each part of the code was expecting

some kind of module source, but because of delegation, it wasn't

really possible to add/mix more sources.

This commit refactors this concept into a `ModuleSources` concept

which allows storing more information about a module source, in

a safe and consistent manner. No more wrapping/unwrapping, and each

code requiring a specific type of module source can query for it.

  1. … 64 more files in changeset.
Refactor `ModuleSource`

The `ModuleSource` concept was a bit messy. It was designed in order

to be able to store the origin of an artifact. Over time, it evolved

into storing more information, like snapshot timestamps, repositories

or content hash.

The code was convoluted because each part of the code was expecting

some kind of module source, but because of delegation, it wasn't

really possible to add/mix more sources.

This commit refactors this concept into a `ModuleSources` concept

which allows storing more information about a module source, in

a safe and consistent manner. No more wrapping/unwrapping, and each

code requiring a specific type of module source can query for it.

  1. … 63 more files in changeset.
Inject PlatformSupport into component metadata handler

This gives access to the typed version for the 'category=platform'

attribute value.

    • -3
    • +3
    ./ComponentMetadataDetailsAdapterTest.groovy
  1. … 8 more files in changeset.
Reuse one object for empty ComponentOverrideMetadata

  1. … 3 more files in changeset.
Reuse one object for empty ComponentOverrideMetadata

  1. … 3 more files in changeset.
Reuse one object for empty ComponentOverrideMetadata

  1. … 3 more files in changeset.
Reuse one object for empty ComponentOverrideMetadata

  1. … 3 more files in changeset.
Reuse one object for empty ComponentOverrideMetadata

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

This reverts commit 67b8bb8f18f854f45a2f5ec52cc9c8a25981e2f2.

This restores the merge attempt from earlier.

    • -2
    • +2
    ./ComponentMetadataDetailsAdapterTest.groovy
  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.

    • -2
    • +2
    ./ComponentMetadataDetailsAdapterTest.groovy
  1. … 66 more files in changeset.
Changes in Gradle Module Metadata loading

We no longer define any configurations, like default or the maven ones.

In the past, we still had these defined which allowed partial legacy

selection. But it made no sense since all these configurations would not

have any dependencies for example.

Fixes #10980

    • -2
    • +2
    ./ComponentMetadataDetailsAdapterTest.groovy
  1. … 16 more files in changeset.
Changes in Gradle Module Metadata generation

We no longer define any configurations, like default or the maven ones.

In the past, we still had these defined which allowed partial legacy

selection. But it made no sense since all these configurations would not

have any dependencies for example.

    • -2
    • +2
    ./ComponentMetadataDetailsAdapterTest.groovy
  1. … 16 more files in changeset.
Rename inheritStrictVersions() -> endorseStrictVersions() (#10755)

This name change more clearly communicates the semantics of the

feature from a users point of view.

This commit also removes all mentions of 'inheriting' AND 'forSubgraph'.

There have been some leftovers in documentation/comments that

would have been misleading in the future. To make sure we catch all,

this also updates all variable/method/package names.

    • -6
    • +6
    ./DependenciesMetadataAdapterTest.groovy
  1. … 70 more files in changeset.
Rename inheritStrictVersions() -> endorseStrictVersions()

This is more clearly communicating the semantics of the feature

from a users point of view.

The commit also removes all mentions of 'inheriting' AND 'forSubgraph'.

There have been some leftovers in documentation/comments that

will be misleading in the future. To make sure we catch all,

I also updated all variable/method/package names.

    • -6
    • +6
    ./DependenciesMetadataAdapterTest.groovy
  1. … 70 more files in changeset.
Rename inheritStrictVersions() -> endorseStrictVersions()

This is more clearly communicating the semantics of the feature

from a users point of view.

The commit also removes all mentions of 'inheriting' AND 'forSubgraph'.

There have been some leftovers in documentation/comments that

will be misleading in the future. To make sure we catch all,

I also updated all variable/method/package names.

    • -6
    • +6
    ./DependenciesMetadataAdapterTest.groovy
  1. … 70 more files in changeset.
Rename inheritStrictVersions() -> endorseStrictVersions()

This is more clearly communicating the semantics of the feature

from a users point of view.

The commit also removes all mentions of 'inheriting' AND 'forSubgraph'.

There have been some leftovers in documentation/comments that

will be misleading in the future. To make sure we catch all,

I also updated all variable/method/package names.

    • -6
    • +6
    ./DependenciesMetadataAdapterTest.groovy
  1. … 70 more files in changeset.
Support adding variants and files in component metadata rules (#10368)

Support adding variants and files in component metadata rules

  1. … 2 more files in changeset.
Updates to terminology for clarity

- `inheritStrictConstraints` -> `inheritStrictVersions`

- `notInheritStrictConstraints` -> `doNotInheritStrictVersions`

    • -2
    • +2
    ./DependenciesMetadataAdapterTest.groovy
  1. … 31 more files in changeset.
Updates to terminology for clarity

- `inheritStrictConstraints` -> `inheritStrictVersions`

- `notInheritStrictConstraints` -> `doNotInheritStrictVersions`

    • -2
    • +2
    ./DependenciesMetadataAdapterTest.groovy
  1. … 31 more files in changeset.
Updates to terminology for clarity

- `inheritStrictConstraints` -> `inheritStrictVersions`

- `notInheritStrictConstraints` -> `doNotInheritStrictVersions`

    • -2
    • +2
    ./DependenciesMetadataAdapterTest.groovy
  1. … 31 more files in changeset.
Updates to terminology for clarity

- `inheritStrictConstraints` -> `inheritStrictVersions`

- `notInheritStrictConstraints` -> `doNotInheritStrictVersions`

    • -2
    • +2
    ./DependenciesMetadataAdapterTest.groovy
  1. … 31 more files in changeset.
Updates to terminology for clarity

- `inheritStrictConstraints` -> `inheritStrictVersions`

- `notInheritStrictConstraints` -> `doNotInheritStrictVersions`

    • -2
    • +2
    ./DependenciesMetadataAdapterTest.groovy
  1. … 31 more files in changeset.
Updates to terminology for clarity

- `inheritStrictConstraints` -> `inheritStrictVersions`

- `notInheritStrictConstraints` -> `doNotInheritStrictVersions`

    • -2
    • +2
    ./DependenciesMetadataAdapterTest.groovy
  1. … 30 more files in changeset.