Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Fix inconsistent resolution ordering

The fix for #12951 introduced by #12957 worked but made a number

of other bugs much more likely to happen: by using the right derivation

strategy in each project, we were properly fetching the component

metadata we wanted to process from the cache.

However, this component metadata was mutable, because of laziness.

In particular, derivation of variants require to set the derivation

strategy on "deemed immutable" metadata. The problem is that when

several configurations are resolved concurrently, we ended up mutating

the same component from different threads, with different derivation

strategies.

The ideal fix would be to have real immutable component metadata from

the cache. However, because of laziness (required for performance), we

can't do that.

The fix in this PR is therefore to create a copy of the module metadata

whenever a different derivation strategy needs to be used.

It also highlighted another bug, which is that when we use cached

component metadata rules, the derivation strategy wasn't part of the

cache key, meaning that we would get whatever was first stored in the

binary cache.

We now properly separate the entries in the cache by amending the cache

key with the name of the strategy. This isn't ideal as we could potentially

have _stateful_ strategies, but for now there are no such things in the

wild. Again in reality we'd like to get rid of the "magic snapshotting"

of rules and do something similar to what transforms do, with proper

declared input types.

Fixes #13555

    • -5
    • +14
    ./DefaultMavenModuleResolveMetadata.java
    • -3
    • +12
    ./RealisedMavenModuleResolveMetadata.java
  1. … 17 more files in changeset.
Fix inconsistent resolution ordering

The fix for #12951 introduced by #12957 worked but made a number

of other bugs much more likely to happen: by using the right derivation

strategy in each project, we were properly fetching the component

metadata we wanted to process from the cache.

However, this component metadata was mutable, because of laziness.

In particular, derivation of variants require to set the derivation

strategy on "deemed immutable" metadata. The problem is that when

several configurations are resolved concurrently, we ended up mutating

the same component from different threads, with different derivation

strategies.

The ideal fix would be to have real immutable component metadata from

the cache. However, because of laziness (required for performance), we

can't do that.

The fix in this PR is therefore to create a copy of the module metadata

whenever a different derivation strategy needs to be used.

It also highlighted another bug, which is that when we use cached

component metadata rules, the derivation strategy wasn't part of the

cache key, meaning that we would get whatever was first stored in the

binary cache.

We now properly separate the entries in the cache by amending the cache

key with the name of the strategy. This isn't ideal as we could potentially

have _stateful_ strategies, but for now there are no such things in the

wild. Again in reality we'd like to get rid of the "magic snapshotting"

of rules and do something similar to what transforms do, with proper

declared input types.

Fixes #13555

    • -5
    • +14
    ./DefaultMavenModuleResolveMetadata.java
    • -3
    • +12
    ./RealisedMavenModuleResolveMetadata.java
  1. … 14 more files in changeset.
Fix inconsistent resolution ordering

The fix for #12951 introduced by #12957 worked but made a number

of other bugs much more likely to happen: by using the right derivation

strategy in each project, we were properly fetching the component

metadata we wanted to process from the cache.

However, this component metadata was mutable, because of laziness.

In particular, derivation of variants require to set the derivation

strategy on "deemed immutable" metadata. The problem is that when

several configurations are resolved concurrently, we ended up mutating

the same component from different threads, with different derivation

strategies.

The ideal fix would be to have real immutable component metadata from

the cache. However, because of laziness (required for performance), we

can't do that.

The fix in this PR is therefore to create a copy of the module metadata

whenever a different derivation strategy needs to be used.

It also highlighted another bug, which is that when we use cached

component metadata rules, the derivation strategy wasn't part of the

cache key, meaning that we would get whatever was first stored in the

binary cache.

We now properly separate the entries in the cache by amending the cache

key with the name of the strategy. This isn't ideal as we could potentially

have _stateful_ strategies, but for now there are no such things in the

wild. Again in reality we'd like to get rid of the "magic snapshotting"

of rules and do something similar to what transforms do, with proper

declared input types.

Fixes #13555

    • -5
    • +14
    ./DefaultMavenModuleResolveMetadata.java
    • -3
    • +12
    ./RealisedMavenModuleResolveMetadata.java
  1. … 17 more files in changeset.
Fix inconsistent resolution ordering

The fix for #12951 introduced by #12957 worked but made a number

of other bugs much more likely to happen: by using the right derivation

strategy in each project, we were properly fetching the component

metadata we wanted to process from the cache.

However, this component metadata was mutable, because of laziness.

In particular, derivation of variants require to set the derivation

strategy on "deemed immutable" metadata. The problem is that when

several configurations are resolved concurrently, we ended up mutating

the same component from different threads, with different derivation

strategies.

The ideal fix would be to have real immutable component metadata from

the cache. However, because of laziness (required for performance), we

can't do that.

The fix in this PR is therefore to create a copy of the module metadata

whenever a different derivation strategy needs to be used.

It also highlighted another bug, which is that when we use cached

component metadata rules, the derivation strategy wasn't part of the

cache key, meaning that we would get whatever was first stored in the

binary cache.

We now properly separate the entries in the cache by amending the cache

key with the name of the strategy. This isn't ideal as we could potentially

have _stateful_ strategies, but for now there are no such things in the

wild. Again in reality we'd like to get rid of the "magic snapshotting"

of rules and do something similar to what transforms do, with proper

declared input types.

Fixes #13555

    • -5
    • +14
    ./DefaultMavenModuleResolveMetadata.java
    • -3
    • +12
    ./RealisedMavenModuleResolveMetadata.java
  1. … 17 more files in changeset.
Fix inconsistent resolution ordering

The fix for #12951 introduced by #12957 worked but made a number

of other bugs much more likely to happen: by using the right derivation

strategy in each project, we were properly fetching the component

metadata we wanted to process from the cache.

However, this component metadata was mutable, because of laziness.

In particular, derivation of variants require to set the derivation

strategy on "deemed immutable" metadata. The problem is that when

several configurations are resolved concurrently, we ended up mutating

the same component from different threads, with different derivation

strategies.

The ideal fix would be to have real immutable component metadata from

the cache. However, because of laziness (required for performance), we

can't do that.

The fix in this PR is therefore to create a copy of the module metadata

whenever a different derivation strategy needs to be used.

It also highlighted another bug, which is that when we use cached

component metadata rules, the derivation strategy wasn't part of the

cache key, meaning that we would get whatever was first stored in the

binary cache.

We now properly separate the entries in the cache by amending the cache

key with the name of the strategy. This isn't ideal as we could potentially

have _stateful_ strategies, but for now there are no such things in the

wild. Again in reality we'd like to get rid of the "magic snapshotting"

of rules and do something similar to what transforms do, with proper

declared input types.

Fixes #13555

    • -5
    • +14
    ./DefaultMavenModuleResolveMetadata.java
    • -3
    • +12
    ./RealisedMavenModuleResolveMetadata.java
  1. … 17 more files in changeset.
Fix inconsistent resolution ordering

The fix for #12951 introduced by #12957 worked but made a number

of other bugs much more likely to happen: by using the right derivation

strategy in each project, we were properly fetching the component

metadata we wanted to process from the cache.

However, this component metadata was mutable, because of laziness.

In particular, derivation of variants require to set the derivation

strategy on "deemed immutable" metadata. The problem is that when

several configurations are resolved concurrently, we ended up mutating

the same component from different threads, with different derivation

strategies.

The ideal fix would be to have real immutable component metadata from

the cache. However, because of laziness (required for performance), we

can't do that.

The fix in this PR is therefore to create a copy of the module metadata

whenever a different derivation strategy needs to be used.

It also highlighted another bug, which is that when we use cached

component metadata rules, the derivation strategy wasn't part of the

cache key, meaning that we would get whatever was first stored in the

binary cache.

We now properly separate the entries in the cache by amending the cache

key with the name of the strategy. This isn't ideal as we could potentially

have _stateful_ strategies, but for now there are no such things in the

wild. Again in reality we'd like to get rid of the "magic snapshotting"

of rules and do something similar to what transforms do, with proper

declared input types.

Fixes #13555

    • -5
    • +14
    ./DefaultMavenModuleResolveMetadata.java
    • -3
    • +12
    ./RealisedMavenModuleResolveMetadata.java
  1. … 12 more files in changeset.
Fix inconsistent resolution ordering

The fix for #12951 introduced by #12957 worked but made a number

of other bugs much more likely to happen: by using the right derivation

strategy in each project, we were properly fetching the component

metadata we wanted to process from the cache.

However, this component metadata was mutable, because of laziness.

In particular, derivation of variants require to set the derivation

strategy on "deemed immutable" metadata. The problem is that when

several configurations are resolved concurrently, we ended up mutating

the same component from different threads, with different derivation

strategies.

The ideal fix would be to have real immutable component metadata from

the cache. However, because of laziness (required for performance), we

can't do that.

The fix in this PR is therefore to create a copy of the module metadata

whenever a different derivation strategy needs to be used.

It also highlighted another bug, which is that when we use cached

component metadata rules, the derivation strategy wasn't part of the

cache key, meaning that we would get whatever was first stored in the

binary cache.

We now properly separate the entries in the cache by amending the cache

key with the name of the strategy. This isn't ideal as we could potentially

have _stateful_ strategies, but for now there are no such things in the

wild. Again in reality we'd like to get rid of the "magic snapshotting"

of rules and do something similar to what transforms do, with proper

declared input types.

Fixes #13555

    • -5
    • +14
    ./DefaultMavenModuleResolveMetadata.java
    • -3
    • +12
    ./RealisedMavenModuleResolveMetadata.java
  1. … 14 more files in changeset.
Clean up warnings

This includes cleaning up compilation warnings and other warnings from

IDE inspection.

One large area of changes was around having proper @Nullable /

@NonNullApi to clarify nullability.

    • -5
    • +4
    ./DefaultMavenModuleResolveMetadata.java
    • -2
    • +2
    ./DefaultMutableMavenModuleResolveMetadata.java
    • -1
    • +1
    ./RealisedMavenModuleResolveMetadata.java
  1. … 324 more files in changeset.
Clean up warnings

This includes cleaning up compilation warnings and other warnings from

IDE inspection.

One large area of changes was around having proper @Nullable /

@NonNullApi to clarify nullability.

    • -5
    • +4
    ./DefaultMavenModuleResolveMetadata.java
    • -2
    • +2
    ./DefaultMutableMavenModuleResolveMetadata.java
    • -1
    • +1
    ./RealisedMavenModuleResolveMetadata.java
  1. … 324 more files in changeset.
Clean up warnings

This includes cleaning up compilation warnings and other warnings from

IDE inspection.

One large area of changes was around having proper @Nullable /

@NonNullApi to clarify nullability.

    • -5
    • +4
    ./DefaultMavenModuleResolveMetadata.java
    • -2
    • +2
    ./DefaultMutableMavenModuleResolveMetadata.java
    • -1
    • +1
    ./RealisedMavenModuleResolveMetadata.java
  1. … 324 more files in changeset.
Clean up warnings

This includes cleaning up compilation warnings and other warnings from

IDE inspection.

One large area of changes was around having proper @Nullable /

@NonNullApi to clarify nullability.

    • -5
    • +4
    ./DefaultMavenModuleResolveMetadata.java
    • -2
    • +2
    ./DefaultMutableMavenModuleResolveMetadata.java
    • -1
    • +1
    ./RealisedMavenModuleResolveMetadata.java
  1. … 324 more files in changeset.
Clean up warnings

This includes cleaning up compilation warnings and other warnings from

IDE inspection.

One large area of changes was around having proper @Nullable /

@NonNullApi to clarify nullability.

    • -5
    • +4
    ./DefaultMavenModuleResolveMetadata.java
    • -2
    • +2
    ./DefaultMutableMavenModuleResolveMetadata.java
    • -1
    • +1
    ./RealisedMavenModuleResolveMetadata.java
  1. … 324 more files in changeset.
Clean up warnings

This includes cleaning up compilation warnings and other warnings from

IDE inspection.

One large area of changes was around having proper @Nullable /

@NonNullApi to clarify nullability.

    • -5
    • +4
    ./DefaultMavenModuleResolveMetadata.java
    • -2
    • +2
    ./DefaultMutableMavenModuleResolveMetadata.java
    • -1
    • +1
    ./RealisedMavenModuleResolveMetadata.java
  1. … 324 more files in changeset.
WIP

    • -2
    • +11
    ./RealisedMavenModuleResolveMetadata.java
  1. … 2 more files in changeset.
Add lenient version of ComponentMetadataDetails.addVariant() (#11565)

    • -10
    • +13
    ./RealisedMavenModuleResolveMetadata.java
  1. … 10 more files in changeset.
Add lenient version of ComponentMetadataDetails.addVariant()

    • -10
    • +13
    ./RealisedMavenModuleResolveMetadata.java
  1. … 10 more files in changeset.
Add lenient version of ComponentMetadataDetails.addVariant()

    • -10
    • +13
    ./RealisedMavenModuleResolveMetadata.java
  1. … 9 more files in changeset.
Add lenient version of ComponentMetadataDetails.addVariant()

    • -10
    • +13
    ./RealisedMavenModuleResolveMetadata.java
  1. … 8 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.

    • -7
    • +7
    ./DefaultMavenModuleResolveMetadata.java
    • -5
    • +5
    ./RealisedMavenModuleResolveMetadata.java
  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.

    • -8
    • +3
    ./DefaultMavenModuleResolveMetadata.java
    • -8
    • +3
    ./RealisedMavenModuleResolveMetadata.java
  1. … 60 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.

    • -7
    • +7
    ./DefaultMavenModuleResolveMetadata.java
    • -5
    • +5
    ./RealisedMavenModuleResolveMetadata.java
  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.

    • -7
    • +8
    ./DefaultMavenModuleResolveMetadata.java
    • -5
    • +5
    ./RealisedMavenModuleResolveMetadata.java
  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.

    • -8
    • +3
    ./DefaultMavenModuleResolveMetadata.java
    • -8
    • +3
    ./RealisedMavenModuleResolveMetadata.java
  1. … 61 more files in changeset.
Remove offending 'break' from loop

    • -1
    • +0
    ./RealisedMavenModuleResolveMetadataSerializationHelper.java
Fixes to support of snapshots with module metadata

* Properly saves the timestamp information in the metadata cache

* Properly considers snapshots as changing modules

Fixes #11050

    • -0
    • +14
    ./DefaultMutableMavenModuleResolveMetadata.java
  1. … 2 more files in changeset.
Revert "Revert "Merge branch 'release'""

This reverts commit 67b8bb8f18f854f45a2f5ec52cc9c8a25981e2f2.

This restores the merge attempt from earlier.

    • -1
    • +13
    ./DefaultMutableMavenModuleResolveMetadata.java
  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.

    • -13
    • +1
    ./DefaultMutableMavenModuleResolveMetadata.java
  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

    • -1
    • +13
    ./DefaultMutableMavenModuleResolveMetadata.java
  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.

    • -1
    • +13
    ./DefaultMutableMavenModuleResolveMetadata.java
  1. … 16 more files in changeset.
Fix application of dependency rules in realized metadata version

The rules for dependencies and dependency constraints were not applied

if the variant itself was added by a rule.

This commit also no longer attempts to apply any rule to the realized

version of 'pure maven configurations'. For Maven, we always use the

derived variants and always use variant matching. Therefore, rules are

never applied to the legacy configurations, but only to the derived

variants.

Follow up to #10368

    • -14
    • +16
    ./RealisedMavenModuleResolveMetadata.java
  1. … 2 more files in changeset.