Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
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
    ./model/ivy/RealisedIvyModuleResolveMetadata.java
    • -14
    • +16
    ./model/maven/RealisedMavenModuleResolveMetadata.java
  1. … 1 more file 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
    ./model/ivy/RealisedIvyModuleResolveMetadata.java
    • -5
    • +7
    ./model/maven/RealisedMavenModuleResolveMetadata.java
  1. … 1 more file in changeset.
Updates to terminology for clarity

- `inheritStrictConstraints` -> `inheritStrictVersions`

- `notInheritStrictConstraints` -> `doNotInheritStrictVersions`

    • -1
    • +1
    ./model/ConfigurationBoundExternalDependencyMetadata.java
    • -2
    • +2
    ./model/ForcedDependencyMetadataWrapper.java
    • -2
    • +2
    ./model/ModuleDependencyMetadataWrapper.java
  1. … 27 more files in changeset.
Updates to terminology for clarity

- `inheritStrictConstraints` -> `inheritStrictVersions`

- `notInheritStrictConstraints` -> `doNotInheritStrictVersions`

    • -1
    • +1
    ./model/ConfigurationBoundExternalDependencyMetadata.java
    • -2
    • +2
    ./model/ForcedDependencyMetadataWrapper.java
    • -2
    • +2
    ./model/ModuleDependencyMetadataWrapper.java
  1. … 27 more files in changeset.
Updates to terminology for clarity

- `inheritStrictConstraints` -> `inheritStrictVersions`

- `notInheritStrictConstraints` -> `doNotInheritStrictVersions`

    • -1
    • +1
    ./model/ConfigurationBoundExternalDependencyMetadata.java
    • -2
    • +2
    ./model/ForcedDependencyMetadataWrapper.java
    • -2
    • +2
    ./model/ModuleDependencyMetadataWrapper.java
  1. … 27 more files in changeset.
Updates to terminology for clarity

- `inheritStrictConstraints` -> `inheritStrictVersions`

- `notInheritStrictConstraints` -> `doNotInheritStrictVersions`

    • -1
    • +1
    ./model/ConfigurationBoundExternalDependencyMetadata.java
    • -2
    • +2
    ./model/ForcedDependencyMetadataWrapper.java
    • -2
    • +2
    ./model/ModuleDependencyMetadataWrapper.java
  1. … 27 more files in changeset.
Updates to terminology for clarity

- `inheritStrictConstraints` -> `inheritStrictVersions`

- `notInheritStrictConstraints` -> `doNotInheritStrictVersions`

    • -1
    • +1
    ./model/ConfigurationBoundExternalDependencyMetadata.java
    • -2
    • +2
    ./model/ForcedDependencyMetadataWrapper.java
    • -2
    • +2
    ./model/ModuleDependencyMetadataWrapper.java
  1. … 27 more files in changeset.
Updates to terminology for clarity

- `inheritStrictConstraints` -> `inheritStrictVersions`

- `notInheritStrictConstraints` -> `doNotInheritStrictVersions`

    • -1
    • +1
    ./model/ConfigurationBoundExternalDependencyMetadata.java
    • -2
    • +2
    ./model/ForcedDependencyMetadataWrapper.java
    • -2
    • +2
    ./model/ModuleDependencyMetadataWrapper.java
  1. … 26 more files in changeset.
Rework `forSubgraph` as implied by `strictly`

This commit removes a dedicated `forSubgraph` flag

on version constraints, so that it is _implied_ by

strict version constraints. This simplifies the behavior

of `strictly`, making it closer to the intuitive semantics,

while maintaining the ability to fail the build if a

consumer brings an incompatible version in the graph.

As a consequence, _strict dependencies_ now express that

the producer preference overrides whatever is found in

its own dependency graph. It is closer to the "nearest

first" semantics of Maven, while not having its drawbacks

(ordering in particular).

    • -1
    • +1
    ./ivypublish/DefaultIvyModulePublishMetadata.java
    • -1
    • +1
    ./model/ConfigurationBoundExternalDependencyMetadata.java
    • -2
    • +2
    ./model/ForcedDependencyMetadataWrapper.java
    • -2
    • +2
    ./model/ModuleDependencyMetadataWrapper.java
  1. … 72 more files in changeset.
Rework `forSubgraph` as implied by `strictly`

This commit removes a dedicated `forSubgraph` flag

on version constraints, so that it is _implied_ by

strict version constraints. This simplifies the behavior

of `strictly`, making it closer to the intuitive semantics,

while maintaining the ability to fail the build if a

consumer brings an incompatible version in the graph.

As a consequence, _strict dependencies_ now express that

the producer preference overrides whatever is found in

its own dependency graph. It is closer to the "nearest

first" semantics of Maven, while not having its drawbacks

(ordering in particular).

    • -1
    • +1
    ./ivypublish/DefaultIvyModulePublishMetadata.java
    • -1
    • +1
    ./model/ConfigurationBoundExternalDependencyMetadata.java
    • -2
    • +2
    ./model/ForcedDependencyMetadataWrapper.java
    • -2
    • +2
    ./model/ModuleDependencyMetadataWrapper.java
  1. … 74 more files in changeset.
Rework `forSubgraph` as implied by `strictly`

This commit removes a dedicated `forSubgraph` flag

on version constraints, so that it is _implied_ by

strict version constraints. This simplifies the behavior

of `strictly`, making it closer to the intuitive semantics,

while maintaining the ability to fail the build if a

consumer brings an incompatible version in the graph.

As a consequence, _strict dependencies_ now express that

the producer preference overrides whatever is found in

its own dependency graph. It is closer to the "nearest

first" semantics of Maven, while not having its drawbacks

(ordering in particular).

    • -1
    • +1
    ./ivypublish/DefaultIvyModulePublishMetadata.java
    • -1
    • +1
    ./model/ConfigurationBoundExternalDependencyMetadata.java
    • -2
    • +2
    ./model/ForcedDependencyMetadataWrapper.java
    • -2
    • +2
    ./model/ModuleDependencyMetadataWrapper.java
  1. … 72 more files in changeset.
Rework `forSubgraph` as implied by `strictly`

This commit removes a dedicated `forSubgraph` flag

on version constraints, so that it is _implied_ by

strict version constraints. This simplifies the behavior

of `strictly`, making it closer to the intuitive semantics,

while maintaining the ability to fail the build if a

consumer brings an incompatible version in the graph.

As a consequence, _strict dependencies_ now express that

the producer preference overrides whatever is found in

its own dependency graph. It is closer to the "nearest

first" semantics of Maven, while not having its drawbacks

(ordering in particular).

    • -1
    • +1
    ./ivypublish/DefaultIvyModulePublishMetadata.java
    • -1
    • +1
    ./model/ConfigurationBoundExternalDependencyMetadata.java
    • -2
    • +2
    ./model/ForcedDependencyMetadataWrapper.java
    • -2
    • +2
    ./model/ModuleDependencyMetadataWrapper.java
  1. … 72 more files in changeset.
Rework `forSubgraph` as implied by `strictly`

This commit removes a dedicated `forSubgraph` flag

on version constraints, so that it is _implied_ by

strict version constraints. This simplifies the behavior

of `strictly`, making it closer to the intuitive semantics,

while maintaining the ability to fail the build if a

consumer brings an incompatible version in the graph.

As a consequence, _strict dependencies_ now express that

the producer preference overrides whatever is found in

its own dependency graph. It is closer to the "nearest

first" semantics of Maven, while not having its drawbacks

(ordering in particular).

    • -1
    • +1
    ./ivypublish/DefaultIvyModulePublishMetadata.java
    • -1
    • +1
    ./model/ConfigurationBoundExternalDependencyMetadata.java
    • -2
    • +2
    ./model/ForcedDependencyMetadataWrapper.java
    • -2
    • +2
    ./model/ModuleDependencyMetadataWrapper.java
  1. … 72 more files in changeset.
Rework `forSubgraph` as implied by `strictly`

This commit removes a dedicated `forSubgraph` flag

on version constraints, so that it is _implied_ by

strict version constraints. This simplifies the behavior

of `strictly`, making it closer to the intuitive semantics,

while maintaining the ability to fail the build if a

consumer brings an incompatible version in the graph.

As a consequence, _strict dependencies_ now express that

the producer preference overrides whatever is found in

its own dependency graph. It is closer to the "nearest

first" semantics of Maven, while not having its drawbacks

(ordering in particular).

    • -1
    • +1
    ./ivypublish/DefaultIvyModulePublishMetadata.java
    • -1
    • +1
    ./model/ConfigurationBoundExternalDependencyMetadata.java
    • -2
    • +2
    ./model/ForcedDependencyMetadataWrapper.java
    • -2
    • +2
    ./model/ModuleDependencyMetadataWrapper.java
  1. … 72 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

    • -3
    • +8
    ./model/AbstractConfigurationMetadata.java
    • -2
    • +2
    ./model/AbstractMutableModuleComponentResolveMetadata.java
    • -0
    • +45
    ./model/AbstractRealisedModuleResolveMetadataSerializationHelper.java
    • -8
    • +5
    ./model/DefaultConfigurationMetadata.java
    • -8
    • +60
    ./model/LazyToRealisedModuleComponentResolveMetadataHelper.java
    • -1
    • +1
    ./model/LazyVariantBackedConfigurationMetadata.java
    • -5
    • +18
    ./model/RealisedConfigurationMetadata.java
    • -0
    • +6
    ./model/UrlBackedArtifactMetadata.java
    • -18
    • +98
    ./model/ivy/RealisedIvyModuleResolveMetadata.java
    • -11
    • +26
    ./model/ivy/RealisedIvyModuleResolveMetadataSerializationHelper.java
    • -22
    • +72
    ./model/maven/RealisedMavenModuleResolveMetadata.java
    • -3
    • +10
    ./model/maven/RealisedMavenModuleResolveMetadataSerializationHelper.java
  1. … 3 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

    • -2
    • +2
    ./model/AbstractMutableModuleComponentResolveMetadata.java
    • -0
    • +45
    ./model/AbstractRealisedModuleResolveMetadataSerializationHelper.java
    • -1
    • +1
    ./model/DefaultConfigurationMetadata.java
    • -8
    • +60
    ./model/LazyToRealisedModuleComponentResolveMetadataHelper.java
    • -1
    • +1
    ./model/LazyVariantBackedConfigurationMetadata.java
    • -0
    • +6
    ./model/UrlBackedArtifactMetadata.java
    • -17
    • +97
    ./model/ivy/RealisedIvyModuleResolveMetadata.java
    • -11
    • +18
    ./model/ivy/RealisedIvyModuleResolveMetadataSerializationHelper.java
    • -21
    • +68
    ./model/maven/RealisedMavenModuleResolveMetadata.java
    • -2
    • +5
    ./model/maven/RealisedMavenModuleResolveMetadataSerializationHelper.java
  1. … 2 more files in changeset.
Serialize dependency artifacts in for realized variant of metadata

Addition to #10372

    • -2
    • +3
    ./model/AbstractRealisedModuleResolveMetadataSerializationHelper.java
    • -4
    • +4
    ./model/AbstractVariantBackedConfigurationMetadata.java
    • -1
    • +11
    ./model/GradleDependencyMetadata.java
    • -4
    • +4
    ./model/LazyToRealisedModuleComponentResolveMetadataHelper.java
  1. … 3 more files in changeset.
Serialize dependency artifacts in for realized variant of metadata

Addition to #10372

    • -2
    • +3
    ./model/AbstractRealisedModuleResolveMetadataSerializationHelper.java
    • -4
    • +4
    ./model/AbstractVariantBackedConfigurationMetadata.java
    • -1
    • +10
    ./model/GradleDependencyMetadata.java
    • -4
    • +4
    ./model/LazyToRealisedModuleComponentResolveMetadataHelper.java
  1. … 3 more files in changeset.
Make evaluation of base variant rules lazy

    • -1
    • +1
    ./model/AbstractConfigurationMetadata.java
    • -23
    • +3
    ./model/AbstractLazyModuleComponentResolveMetadata.java
    • -1
    • +1
    ./model/AbstractMutableModuleComponentResolveMetadata.java
    • -0
    • +153
    ./model/LazyRuleAwareWithBaseConfigurationMetadata.java
    • -11
    • +3
    ./model/LazyVariantBackedConfigurationMetadata.java
  1. … 2 more files in changeset.
Make evaluation of base variant rules lazy

    • -1
    • +1
    ./model/AbstractConfigurationMetadata.java
    • -23
    • +3
    ./model/AbstractLazyModuleComponentResolveMetadata.java
    • -1
    • +1
    ./model/AbstractMutableModuleComponentResolveMetadata.java
    • -0
    • +153
    ./model/LazyRuleAwareWithBaseConfigurationMetadata.java
    • -11
    • +3
    ./model/LazyVariantBackedConfigurationMetadata.java
  1. … 2 more files in changeset.
Add a spike implementation of a Homebrew repository, that can locate pre-built libraries in the local Homebrew repository.

    • -1
    • +1
    ./model/AbstractConfigurationMetadata.java
    • -1
    • +1
    ./model/AbstractModuleComponentResolveMetadata.java
  1. … 5 more files in changeset.
Add removeAllFiles() to variant files modification API

Files from an existing 'base' are now also transferred to the new

variant (but can then be removed with removeAllFiles()). This makes:

- The behavior more consistent (before everything was transferred

*except* for the files)

- The 'enrich plain ivy with variants' use case better as you do not

manually have to re-add the files that are already in the configuration

metadata

    • -1
    • +5
    ./model/AbstractLazyModuleComponentResolveMetadata.java
    • -5
    • +8
    ./model/LazyVariantBackedConfigurationMetadata.java
  1. … 13 more files in changeset.
Add removeAllFiles() to variant files modification API

Files from an existing 'base' are now also transferred to the new

variant (but can then be removed with removeAllFiles()). This makes:

- The behavior more consistent (before everything was transferred

*except* for the files)

- The 'enrich plain ivy with variants' use case better as you do not

manually have to re-add the files that are already in the configuration

metadata

    • -1
    • +5
    ./model/AbstractLazyModuleComponentResolveMetadata.java
    • -5
    • +8
    ./model/LazyVariantBackedConfigurationMetadata.java
  1. … 11 more files in changeset.
Add removeAllFiles() to variant files modification API

Files from an existing 'base' are now also transferred to the new

variant (but can then be removed with removeAllFiles()). This makes:

- The behavior more consistent (before everything was transferred

*except* for the files)

- The 'enrich plain ivy with variants' use case better as you do not

manually have to re-add the files that are already in the configuration

metadata

    • -1
    • +5
    ./model/AbstractLazyModuleComponentResolveMetadata.java
    • -5
    • +8
    ./model/LazyVariantBackedConfigurationMetadata.java
  1. … 13 more files in changeset.
Add API method to ad a variant without base

Also extend documentation about 'base' and throw errors if a

non-existing base is defined.

    • -6
    • +16
    ./model/AbstractLazyModuleComponentResolveMetadata.java
  1. … 5 more files in changeset.
Add API method to ad a variant without base

Also extend documentation about 'base' and throw errors if a

non-existing base is defined.

    • -6
    • +16
    ./model/AbstractLazyModuleComponentResolveMetadata.java
  1. … 5 more files in changeset.
Only keep artifacts from pom if the file path is unambiguous

If the packaging indicated in a pom is not in the list of 'known

jar packagings', we assume that the artifact could have the extension

indicated by the packaging. We first test if that artifact exists

with a HEAD request, and only if it does not, we go for the 'jar'

artifact.

Since using a variant file rule disables this mechanism, we remove

such ambiguous artifacts from the modified artifact list to give users

the chance to explicitly state which artifact to expect in the rule

they add anyway.

    • -1
    • +2
    ./model/maven/DefaultMavenModuleResolveMetadata.java
  1. … 2 more files in changeset.
Only keep artifacts from pom if the file path is unambiguous

If the packaging indicated in a pom is not in the list of 'known

jar packagings', we assume that the artifact could have the extension

indicated by the packaging. We first test if that artifact exists

with a HEAD request, and only if it does not, we go for the 'jar'

artifact.

Since using a variant file rule disables this mechanism, we remove

such ambiguous artifacts from the modified artifact list to give users

the chance to explicitly state which artifact to expect in the rule

they add anyway.

    • -1
    • +2
    ./model/maven/DefaultMavenModuleResolveMetadata.java
  1. … 2 more files in changeset.
Derive variants for ivy, if publication matches Java library pattern

    • -0
    • +7
    ./model/ConfigurationBoundExternalDependencyMetadata.java
    • -7
    • +6
    ./model/JavaEcosystemVariantDerivationStrategy.java
    • -0
    • +28
    ./model/ivy/DefaultIvyModuleResolveMetadata.java
    • -4
    • +4
    ./model/maven/DefaultMavenModuleResolveMetadata.java
  1. … 10 more files in changeset.
Fixes

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