Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Lambda-ification of the dependency management project

This makes the code base easier to read.

    • -9
    • +5
    ./DefaultIvyModuleResolveMetadata.java
  1. … 65 more files in changeset.
Lambda-ification of the dependency management project

This makes the code base easier to read.

    • -9
    • +5
    ./DefaultIvyModuleResolveMetadata.java
  1. … 65 more files in changeset.
Lambda-ification of the dependency management project

This makes the code base easier to read.

    • -9
    • +5
    ./DefaultIvyModuleResolveMetadata.java
  1. … 65 more files in changeset.
Lambda-ification of the dependency management project

This makes the code base easier to read.

    • -9
    • +5
    ./DefaultIvyModuleResolveMetadata.java
  1. … 65 more files in changeset.
Add lenient version of ComponentMetadataDetails.addVariant() (#11565)

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

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

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

    • -10
    • +13
    ./RealisedIvyModuleResolveMetadata.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.

    • -8
    • +8
    ./DefaultIvyModuleResolveMetadata.java
    • -6
    • +6
    ./RealisedIvyModuleResolveMetadata.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.

    • -9
    • +4
    ./DefaultIvyModuleResolveMetadata.java
    • -9
    • +4
    ./RealisedIvyModuleResolveMetadata.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.

    • -8
    • +8
    ./DefaultIvyModuleResolveMetadata.java
    • -6
    • +6
    ./RealisedIvyModuleResolveMetadata.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
    • +8
    ./DefaultIvyModuleResolveMetadata.java
    • -6
    • +7
    ./RealisedIvyModuleResolveMetadata.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.

    • -9
    • +4
    ./DefaultIvyModuleResolveMetadata.java
    • -9
    • +4
    ./RealisedIvyModuleResolveMetadata.java
  1. … 61 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

    • -2
    • +1
    ./RealisedIvyModuleResolveMetadata.java
  1. … 2 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 itself variant 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

    • -2
    • +1
    ./RealisedIvyModuleResolveMetadata.java
  1. … 2 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 itself variant was added by a rule.

Follow up to #10368

    • -2
    • +1
    ./RealisedIvyModuleResolveMetadata.java
  1. … 2 more files in changeset.
Support variant and file derivation in realized metadata

This required a couple of changes:

- artifacts are now always explicitly serialized for each configuration

- variant derivation is implemented for variants and for configurations

in maven (derived variants) and ivy

- If a ivy module has configurations (variants) that have been added by

a rule, the realized version uses this information to opt-into

variant aware resolution

    • -18
    • +98
    ./RealisedIvyModuleResolveMetadata.java
    • -11
    • +26
    ./RealisedIvyModuleResolveMetadataSerializationHelper.java
  1. … 14 more files in changeset.
Support variant and file derivation in realized metadata

This required a couple of changes:

- artifacts are now always explicitly serialized for each configuration

- variant derivation is implemented for variants and for configurations

in maven (derived variants) and ivy

- If a ivy module has configurations (variants) that have been added by

a rule, the realized version uses this information to opt-into

variant aware resolution

    • -17
    • +97
    ./RealisedIvyModuleResolveMetadata.java
    • -11
    • +18
    ./RealisedIvyModuleResolveMetadataSerializationHelper.java
  1. … 11 more files in changeset.
Derive variants for ivy, if publication matches Java library pattern

    • -0
    • +28
    ./DefaultIvyModuleResolveMetadata.java
  1. … 13 more files in changeset.
Fixes

    • -5
    • +2
    ./DefaultIvyModuleResolveMetadata.java
  1. … 2 more files in changeset.
Fixes

    • -13
    • +0
    ./DefaultIvyModuleResolveMetadata.java
  1. … 2 more files in changeset.
Fixes

    • -31
    • +1
    ./DefaultIvyModuleResolveMetadata.java
  1. … 8 more files in changeset.
Fixes

    • -5
    • +2
    ./DefaultIvyModuleResolveMetadata.java
  1. … 4 more files in changeset.
Fixes

    • -31
    • +1
    ./DefaultIvyModuleResolveMetadata.java
  1. … 29 more files in changeset.
Fixes

    • -31
    • +1
    ./DefaultIvyModuleResolveMetadata.java
  1. … 19 more files in changeset.
Fixes

    • -31
    • +1
    ./DefaultIvyModuleResolveMetadata.java
  1. … 31 more files in changeset.
Fixes

    • -31
    • +1
    ./DefaultIvyModuleResolveMetadata.java
  1. … 5 more files in changeset.
Derive variants for ivy, if publication matches Java library pattern

    • -0
    • +58
    ./DefaultIvyModuleResolveMetadata.java
  1. … 13 more files in changeset.
Allow variant matching opt-in for ivy through component metadata rules

    • -0
    • +27
    ./DefaultIvyModuleResolveMetadata.java
    • -0
    • +27
    ./RealisedIvyModuleResolveMetadata.java
  1. … 7 more files in changeset.
Allow variant matching opt-in for ivy through component metadata rules

    • -0
    • +27
    ./DefaultIvyModuleResolveMetadata.java
    • -0
    • +27
    ./RealisedIvyModuleResolveMetadata.java
  1. … 7 more files in changeset.