Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Improve error message when build fails because of missing metadata

Gradle 6.0 removed the "artifact" metadata source by default.

This means that if a module is published _only_ with an artifact,

previous version of Gradle would find it, but 6.0 would fail with

a module missing exception.

The problem is that it's hard to realize that the issue comes

from the change of this default artifact sources.

This commit tries to improve the situation by recognizing that

a failure is related to not finding metadata, and in this case

would suggest that if the metadata is missing, it is still

possible that the jar is present.

The drawback of this approach is that we're unsure: if, for

some reason, the module is _really_ absent, then we gave a

wrong advice. This means, in particular, in case of wrong

coordinates.

    • -0
    • +7
    ./IvyBrokenRemoteResolveIntegrationTest.groovy
  1. … 12 more files in changeset.
Improve error message when build fails because of missing metadata

Gradle 6.0 removed the "artifact" metadata source by default.

This means that if a module is published _only_ with an artifact,

previous version of Gradle would find it, but 6.0 would fail with

a module missing exception.

The problem is that it's hard to realize that the issue comes

from the change of this default artifact sources.

This commit tries to improve the situation by recognizing that

a failure is related to not finding metadata, and in this case

would suggest that if the metadata is missing, it is still

possible that the jar is present.

The drawback of this approach is that we're unsure: if, for

some reason, the module is _really_ absent, then we gave a

wrong advice. This means, in particular, in case of wrong

coordinates.

    • -0
    • +7
    ./IvyBrokenRemoteResolveIntegrationTest.groovy
  1. … 6 more files in changeset.
Improve error message when build fails because of missing metadata

Gradle 6.0 removed the "artifact" metadata source by default.

This means that if a module is published _only_ with an artifact,

previous version of Gradle would find it, but 6.0 would fail with

a module missing exception.

The problem is that it's hard to realize that the issue comes

from the change of this default artifact sources.

This commit tries to improve the situation by recognizing that

a failure is related to not finding metadata, and in this case

would suggest that if the metadata is missing, it is still

possible that the jar is present.

The drawback of this approach is that we're unsure: if, for

some reason, the module is _really_ absent, then we gave a

wrong advice. This means, in particular, in case of wrong

coordinates.

    • -0
    • +7
    ./IvyBrokenRemoteResolveIntegrationTest.groovy
  1. … 12 more files in changeset.
Improve error message when build fails because of missing metadata

Gradle 6.0 removed the "artifact" metadata source by default.

This means that if a module is published _only_ with an artifact,

previous version of Gradle would find it, but 6.0 would fail with

a module missing exception.

The problem is that it's hard to realize that the issue comes

from the change of this default artifact sources.

This commit tries to improve the situation by recognizing that

a failure is related to not finding metadata, and in this case

would suggest that if the metadata is missing, it is still

possible that the jar is present.

The drawback of this approach is that we're unsure: if, for

some reason, the module is _really_ absent, then we gave a

wrong advice. This means, in particular, in case of wrong

coordinates.

    • -0
    • +7
    ./IvyBrokenRemoteResolveIntegrationTest.groovy
  1. … 12 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. … 77 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. … 79 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. … 77 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. … 77 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. … 77 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. … 77 more files in changeset.
Make artifact representation in ivy fixture correspond to publishing

We never publish an aritfact with 'conf=*' but always list

the configurations it is included in.

    • -1
    • +1
    ./ComponentSelectionRulesDependencyResolveIntegTest.groovy
  1. … 1 more file in changeset.
Clean up IvyPublication and publish more information to ivy.xml metadata

This cleans up the implementation of `populateFromComponent()` and

introduces the following changes that publish information which

was lossy before:

- Artifacts are now added to all configurations they belong to and

not just the first found

- Dependencies are now added for all configurations they belong to,

with the corresponding mapping and version, and

not just for the first found

- For a Java library, this means the 'runtime' now represents the full

runtime variant of the library (before, only 'default' represented

that)

    • -1
    • +1
    ./ComponentSelectionRulesDependencyResolveIntegTest.groovy
    • -8
    • +13
    ./IvyDescriptorDependencyExcludeResolveIntegrationTest.groovy
  1. … 14 more files in changeset.
Clean up IvyPublication and publish more information to ivy.xml metadata

This cleans up the implementation of `populateFromComponent()` and

introduces the following changes that publish information which

was lossy before:

- Artifacts are now added to all configurations they belong to and

not just the first found

- Dependencies are now added for all configurations they belong to,

with the corresponding mapping and version, and

not just for the first found

- For a Java library, this means the 'runtime' now represents the full

runtime variant of the library (before, only 'default' represented

that)

    • -8
    • +13
    ./IvyDescriptorDependencyExcludeResolveIntegrationTest.groovy
  1. … 14 more files in changeset.
Adjust test fixtures and test to ivy behavior changes

    • -0
    • +2
    ./IvyDynamicRevisionRemoteResolveIntegrationTest.groovy
    • -0
    • +1
    ./IvyGradleMetadataRedirectionIntegrationTest.groovy
  1. … 37 more files in changeset.
Fixes

    • -0
    • +2
    ./IvyDynamicRevisionRemoteResolveIntegrationTest.groovy
    • -0
    • +1
    ./IvyGradleMetadataRedirectionIntegrationTest.groovy
  1. … 7 more files in changeset.
Fixes

    • -0
    • +2
    ./IvyDynamicRevisionRemoteResolveIntegrationTest.groovy
    • -0
    • +1
    ./IvyGradleMetadataRedirectionIntegrationTest.groovy
  1. … 28 more files in changeset.
Fixes

    • -0
    • +2
    ./IvyDynamicRevisionRemoteResolveIntegrationTest.groovy
    • -0
    • +1
    ./IvyGradleMetadataRedirectionIntegrationTest.groovy
  1. … 18 more files in changeset.
Fixes

    • -0
    • +2
    ./IvyDynamicRevisionRemoteResolveIntegrationTest.groovy
    • -0
    • +1
    ./IvyGradleMetadataRedirectionIntegrationTest.groovy
  1. … 30 more files in changeset.
Use ivy derivation rules in resolve tests

This allows us to get rid of some special casing in tests that

do not specifically test ivy-only behavior. This tests that common

variant aware dependency management scenarios work for ivy if used

in the recommended way.

    • -6
    • +9
    ./ComponentSelectionRulesErrorHandlingIntegTest.groovy
  1. … 12 more files in changeset.
Use ivy derivation rules in resolve tests

This allows us to get rid of some special casing in tests that

do not specifically test ivy-only behavior. This tests that common

variant aware dependency management scenarios work for ivy if used

in the recommended way.

    • -6
    • +9
    ./ComponentSelectionRulesErrorHandlingIntegTest.groovy
  1. … 12 more files in changeset.
Allow variant matching opt-in for ivy through component metadata rules

    • -6
    • +9
    ./ComponentSelectionRulesErrorHandlingIntegTest.groovy
  1. … 15 more files in changeset.
Allow variant matching opt-in for ivy through component metadata rules

    • -6
    • +9
    ./ComponentSelectionRulesErrorHandlingIntegTest.groovy
  1. … 18 more files in changeset.
Allow variant matching opt-in for ivy through component metadata rules

    • -6
    • +9
    ./ComponentSelectionRulesErrorHandlingIntegTest.groovy
  1. … 20 more files in changeset.
Allow variant matching opt-in for ivy through component metadata rules

    • -6
    • +9
    ./ComponentSelectionRulesErrorHandlingIntegTest.groovy
  1. … 20 more files in changeset.
Align implementations of artifact identifier display names

DefaultModuleComponentArtifactIdentifier now behaves similar as

ComponentFileArtifactIdentifier (showing the full actual file name).

This means that the artifact name used during reporting now

contains the version at the usual position in the file name.

This way it shows the actual file name for artifacts originating

from pom-only maven repositories (except snapshots, which show the

SNAPSHOT placeholder) and ivy repositories with default pattern.

The motivation for this alignment is to get the same representation for

the same file, independent of whether it was sourced from traditional

or Gradle module metadata.

    • -6
    • +1
    ./ComponentSelectionRulesErrorHandlingIntegTest.groovy
    • -3
    • +3
    ./IvyBrokenRemoteResolveIntegrationTest.groovy
    • -1
    • +1
    ./IvyDynamicRevisionRemoteResolveIntegrationTest.groovy
    • -10
    • +10
    ./IvyJvmLibraryArtifactResolutionIntegrationTest.groovy
    • -1
    • +1
    ./IvyModuleArtifactResolutionIntegrationTest.groovy
  1. … 28 more files in changeset.
Align implementations of artifact identifier display names

DefaultModuleComponentArtifactIdentifier now behaves similar as

ComponentFileArtifactIdentifier (showing the full actual file name).

This means that the artifact name used during reporting now

contains the version at the usual position in the file name.

This way it shows the actual file name for artifacts originating

from pom-only maven repositories (except snapshots, which show the

SNAPSHOT placeholder) and ivy repositories with default pattern.

The motivation for this alignment is to get the same representation for

the same file, independent of whether it was sourced from traditional

or Gradle module metadata.

    • -6
    • +1
    ./ComponentSelectionRulesErrorHandlingIntegTest.groovy
    • -3
    • +3
    ./IvyBrokenRemoteResolveIntegrationTest.groovy
    • -1
    • +1
    ./IvyDynamicRevisionRemoteResolveIntegrationTest.groovy
    • -10
    • +10
    ./IvyJvmLibraryArtifactResolutionIntegrationTest.groovy
    • -1
    • +1
    ./IvyModuleArtifactResolutionIntegrationTest.groovy
  1. … 28 more files in changeset.
Module test fixture: add 'category' attribute to api/runtime variants

This reflects the default variant attributes of a published

java component.

    • -1
    • +1
    ./IvyGradleMetadataRedirectionIntegrationTest.groovy
  1. … 13 more files in changeset.
Module test fixture: add 'category' attribute to api/runtime variants

This reflects the default variant attributes of a published

java component.

    • -1
    • +1
    ./IvyGradleMetadataRedirectionIntegrationTest.groovy
  1. … 13 more files in changeset.
Do not drop variant attributes for 'traditional' 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.

    • -1
    • +1
    ./IvyGradleMetadataRedirectionIntegrationTest.groovy
  1. … 27 more files in changeset.
Adjust tests and samples to new metadata sources defaults

    • -9
    • +3
    ./AbstractComponentSelectionRulesIntegrationTest.groovy
    • -4
    • +4
    ./ComponentSelectionRulesDependencyResolveIntegTest.groovy
    • -18
    • +8
    ./ComponentSelectionRulesErrorHandlingIntegTest.groovy
    • -3
    • +1
    ./IvyBrokenDescriptorIntegrationTest.groovy
    • -18
    • +0
    ./IvyBrokenRemoteResolveIntegrationTest.groovy
    • -3
    • +7
    ./IvyDynamicRevisionRemoteResolveIntegrationTest.groovy
    • -2
    • +2
    ./IvyDynamicRevisionResolveIntegrationTest.groovy
    • -2
    • +2
    ./IvyGradleMetadataRedirectionIntegrationTest.groovy
    • -1
    • +0
    ./IvyHttpRepoResolveIntegrationTest.groovy
    • -6
    • +2
    ./IvyJvmLibraryArtifactResolutionIntegrationTest.groovy
    • -1
    • +9
    ./IvyModuleArtifactResolutionIntegrationTest.groovy
    • -2
    • +14
    ./IvyModuleResolveIntegrationTest.groovy
  1. … 83 more files in changeset.