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

    • -10
    • +10
    ./LocalComponentDependencyMetadata.java
  1. … 69 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.

    • -10
    • +10
    ./LocalComponentDependencyMetadata.java
  1. … 69 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.

    • -10
    • +10
    ./LocalComponentDependencyMetadata.java
  1. … 69 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

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

  1. … 12 more files in changeset.
Make evaluation of base variant rules lazy

  1. … 6 more files in changeset.
Make evaluation of base variant rules lazy

  1. … 6 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
    • +1
    ./DefaultSelectedByVariantMatchingConfigurationMetadata.java
    • -1
    • +2
    ./DefaultSelectedByVariantMatchingLocalConfigurationMetadata.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
    • +1
    ./DefaultSelectedByVariantMatchingConfigurationMetadata.java
    • -1
    • +2
    ./DefaultSelectedByVariantMatchingLocalConfigurationMetadata.java
  1. … 9 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
    • +1
    ./DefaultSelectedByVariantMatchingConfigurationMetadata.java
    • -1
    • +2
    ./DefaultSelectedByVariantMatchingLocalConfigurationMetadata.java
  1. … 11 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 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 more files in changeset.
Allow variant matching opt-in for ivy through component metadata rules

  1. … 6 more files in changeset.
Allow variant matching opt-in for ivy through component metadata rules

  1. … 6 more files in changeset.
Allow variant matching opt-in for ivy through component metadata rules

  1. … 13 more files in changeset.
Allow variant matching opt-in for ivy through component metadata rules

  1. … 16 more files in changeset.
Allow variant matching opt-in for ivy through component metadata rules

  1. … 18 more files in changeset.
Allow variant matching opt-in for ivy through component metadata rules

  1. … 18 more files in changeset.
Let resolved variants remember if they were derived

    • -0
    • +5
    ./DefaultSelectedByVariantMatchingConfigurationMetadata.java
  1. … 8 more files in changeset.
Let resolved variants remember if they were derived

    • -0
    • +5
    ./DefaultSelectedByVariantMatchingConfigurationMetadata.java
  1. … 8 more files in changeset.
Let resolved variants remember if they were derived

    • -0
    • +5
    ./DefaultSelectedByVariantMatchingConfigurationMetadata.java
  1. … 8 more files in changeset.
Let resolved variants remember if they were derived

    • -0
    • +5
    ./DefaultSelectedByVariantMatchingConfigurationMetadata.java
  1. … 8 more files in changeset.
Let resolved variants remember if they were derived

    • -0
    • +5
    ./DefaultSelectedByVariantMatchingConfigurationMetadata.java
  1. … 8 more files in changeset.
Let resolved variants remember if they were derived

    • -0
    • +5
    ./DefaultSelectedByVariantMatchingConfigurationMetadata.java
  1. … 8 more files in changeset.
Let resolved variants remember if they were derived

    • -0
    • +5
    ./DefaultSelectedByVariantMatchingConfigurationMetadata.java
  1. … 8 more files in changeset.
Do not drop variant attributes in results based on maven artifacts

FixedComponentArtifacts dropped the variant attributes (stored in

ConfigurationMetadata) for no clear reason. Because of this, the

attributes in the resolve result differed depending on whether the

variant was constructed from pom or GMM.

This is only affecting the attributes reported in the result. During

matching, which happens earlier, all attributes were already considered.

  1. … 17 more files in changeset.
Do not drop variant attributes in results based on maven artifacts

FixedComponentArtifacts dropped the variant attributes (stored in

ConfigurationMetadata) for no clear reason. Because of this, the

attributes in the resolve result differed depending on whether the

variant was constructed from pom or GMM.

This is only affecting the attributes reported in the result. During

matching, which happens earlier, all attributes were already considered.

  1. … 17 more files in changeset.
Do not drop variant attributes in results based on maven artifacts

FixedComponentArtifacts dropped the variant attributes (stored in

ConfigurationMetadata) for no clear reason. Because of this, the

attributes in the resolve result differed depending on whether the

variant was constructed from pom or GMM.

This is only affecting the attributes reported in the result. During

matching, which happens earlier, all attributes were already considered.

  1. … 17 more files in changeset.
Do not drop variant attributes in results based on maven artifacts

FixedComponentArtifacts dropped the variant attributes (stored in

ConfigurationMetadata) for no clear reason. Because of this, the

attributes in the resolve result differed depending on whether the

variant was constructed from pom or GMM.

This is only affecting the attributes reported in the result. During

matching, which happens earlier, all attributes were already considered.

  1. … 17 more files in changeset.
Let resolved variants remember if they were derived

    • -0
    • +5
    ./DefaultSelectedByVariantMatchingConfigurationMetadata.java
  1. … 5 more files in changeset.