MavenSnapshotResolveIntegrationTest.groovy

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Fix snapshot handling with Gradle Module Metadata

This commit fixes a couple of bugs:

1. if Gradle Module Metadata was published and consumed, then

the `changing` flag for the resolved component metadata wouldn't

be set to `true`, which means that snapshot would effectively be

considered as persistent

2. the publish test fixtures were not using the right, timestamped,

version id for the metadata and artifacts in case of unique snapshots,

which caused the resolution to fallback to the POM file

In addition, this fixes the generated module metadata file which

was uploaded _without_ substution the the SNAPSHOT version with

the timestamped version when published on external repositories.

Finally, this highlighted a couple of issues with test fixtures

which were still using Gradle Module Metadata when they shouldn't.

Fixes #10916

    • -2
    • +91
    ./MavenSnapshotResolveIntegrationTest.groovy
  1. … 10 more files in changeset.
Fix snapshot handling with Gradle Module Metadata

This commit fixes a couple of bugs:

1. if Gradle Module Metadata was published and consumed, then

the `changing` flag for the resolved component metadata wouldn't

be set to `true`, which means that snapshot would effectively be

considered as persistent

2. the publish test fixtures were not using the right, timestamped,

version id for the metadata and artifacts in case of unique snapshots,

which caused the resolution to fallback to the POM file

Fixes #10916

    • -2
    • +91
    ./MavenSnapshotResolveIntegrationTest.groovy
  1. … 7 more files in changeset.
Fix snapshot handling with Gradle Module Metadata

This commit fixes a couple of bugs:

1. if Gradle Module Metadata was published and consumed, then

the `changing` flag for the resolved component metadata wouldn't

be set to `true`, which means that snapshot would effectively be

considered as persistent

2. the publish test fixtures were not using the right, timestamped,

version id for the metadata and artifacts in case of unique snapshots,

which caused the resolution to fallback to the POM file

Fixes #10916

    • -2
    • +91
    ./MavenSnapshotResolveIntegrationTest.groovy
  1. … 7 more files in changeset.
Fix snapshot handling with Gradle Module Metadata

This commit fixes a couple of bugs:

1. if Gradle Module Metadata was published and consumed, then

the `changing` flag for the resolved component metadata wouldn't

be set to `true`, which means that snapshot would effectively be

considered as persistent

2. the publish test fixtures were not using the right, timestamped,

version id for the metadata and artifacts in case of unique snapshots,

which caused the resolution to fallback to the POM file

In addition, this fixes the generated module metadata file which

was uploaded _without_ substution the the SNAPSHOT version with

the timestamped version when published on external repositories.

Finally, this highlighted a couple of issues with test fixtures

which were still using Gradle Module Metadata when they shouldn't.

Fixes #10916

    • -2
    • +91
    ./MavenSnapshotResolveIntegrationTest.groovy
  1. … 10 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
    • +1
    ./MavenSnapshotResolveIntegrationTest.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
    • +1
    ./MavenSnapshotResolveIntegrationTest.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
    • +1
    ./MavenSnapshotResolveIntegrationTest.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
    • +1
    ./MavenSnapshotResolveIntegrationTest.groovy
  1. … 12 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.

    • -2
    • +2
    ./MavenSnapshotResolveIntegrationTest.groovy
  1. … 32 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.

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

    • -4
    • +0
    ./MavenSnapshotResolveIntegrationTest.groovy
  1. … 95 more files in changeset.
wip - fix more tests

    • -4
    • +0
    ./MavenSnapshotResolveIntegrationTest.groovy
  1. … 46 more files in changeset.
wip - fix more tests

    • -4
    • +0
    ./MavenSnapshotResolveIntegrationTest.groovy
  1. … 45 more files in changeset.
wip - fix more tests

    • -4
    • +0
    ./MavenSnapshotResolveIntegrationTest.groovy
  1. … 46 more files in changeset.
Let dependency-management tests not use deprecated configurations

    • -2
    • +2
    ./MavenSnapshotResolveIntegrationTest.groovy
  1. … 27 more files in changeset.
Let dependency-management tests not use deprecated configurations

    • -2
    • +2
    ./MavenSnapshotResolveIntegrationTest.groovy
  1. … 27 more files in changeset.
Let dependency-management tests not use deprecated configurations

    • -2
    • +2
    ./MavenSnapshotResolveIntegrationTest.groovy
  1. … 27 more files in changeset.
Let dependency-management tests not use deprecated configurations

    • -2
    • +2
    ./MavenSnapshotResolveIntegrationTest.groovy
  1. … 27 more files in changeset.
Implement variant derivation strategy

This commit changes how Maven metadata is derived into variants. Now we will

only derive variants if the Java plugin is applied (the "base Java" plugin).

This is implemented via a variant derivation strategy, and allows fixing

the problem that a native component is unlikely to find sense in the derivation

of Java variants. This fixes a bug where the native plugins wouldn't be able

to consume native libraries published on Maven repositories, without Gradle

metadata.

    • -0
    • +4
    ./MavenSnapshotResolveIntegrationTest.groovy
  1. … 43 more files in changeset.
Enable improved POM support by default

This commit makes the experimental flag `IMPROVED_POM_SUPPORT` the default.

The flag is still there for backwards compatibility but has effectively no

impact. As a consequence, the behavior of improved POM support is now the

default, which implies that:

- Maven dependencies packaged as `pom` or `jar` now have derived variants

(`compile` and `runtime`) and we properly choose between the variants based

on the consumer attributes

- platform dependencies using the `platform` and `enforcedPlatform` keywords

are enabled

Enabling improved POM support by default is a **breaking change**: there's

a risk that resolved dependencies is different, in particular because we

will now only include the `compile` dependencies of a POM file whenever the

consumer asks for the API variant. There are also some changes in the

dependency insight reports due to the use of attribute based matching instead

of configuration selection.

Last but not least, this commit is likely to introduce a small performance

regression due to attribute based selection.

    • -0
    • +1
    ./MavenSnapshotResolveIntegrationTest.groovy
  1. … 50 more files in changeset.
Improve error reporting in case no matching dynamic version is found

This commit improves rendering of errors in case resolution fails because

all versions in a dynamic range are evicted, and that at least one of the

evicted versions was evicted because of attribute matching. The error will

now report the attributes on each tested version, as well as the requested

attributes.

For this, the module not found exception has been updated to carry more

context, and now makes use of the tree formatter for consistency with other

exceptions in the codebase.

    • -5
    • +5
    ./MavenSnapshotResolveIntegrationTest.groovy
  1. … 37 more files in changeset.
Test timestamped identifier for resolved snapshots

    • -2
    • +40
    ./MavenSnapshotResolveIntegrationTest.groovy
  1. … 4 more files in changeset.
Preserve Maven snapshot ID through dependency resolution

When resolving a Maven snapshot that has a unique timestamp, Gradle internally

generates a unique component identifier for this snapshot. Previously this

unique snapshot id was discarded during resolution, meaning that artifacts from

different unique snapshots could have the same identifier.

With this change, the `MavenUniqueSnapshotIdentifier` is preserved in

resolution, and is made available via the resolution result.

This change is required to fix #3019 for maven snapshots, to avoid the

in-memory cache of resolved artifacts providing a stale result for

unique snapshot artifacts.

    • -8
    • +3
    ./MavenSnapshotResolveIntegrationTest.groovy
  1. … 6 more files in changeset.
Update test to demonstrate current behaviour

ResolutionStrategy configuration is not inherited by child configurations.

This is as expected, so the test has been changed to demonstrate this,

rather than using `@NotYetImplemented` with an assertion of different

behaviour.

    • -20
    • +6
    ./MavenSnapshotResolveIntegrationTest.groovy
Delete long-ignored integration test

    • -80
    • +0
    ./MavenSnapshotResolveIntegrationTest.groovy
Add tests demonstrating gradle#3019

These tests demonstrate that Gradle only considers the cache expiry

policy for the first configuration that resolves a particular

dynamic version or snapshot module. This is particularly problematic

since detached configurations never get any cache expiry configured

via `configurations.all`.

As such, if a detached configuration is the first to resolve a dynamic

version or snapshot during a build invocation, it may cause the user-

configured cache expiry to be ignored. Several popular plugins,

including the Spring dependency management plugin, add detached

configurations that will be resolved early in a build invocation.

    • -0
    • +69
    ./MavenSnapshotResolveIntegrationTest.groovy
  1. … 1 more file in changeset.
Make `MavenMetadataLoader` use `CacheAwareExternalResourceAccessor`

This allows caching the calls to get `maven-metadata.xml`, and, since we now coordinate access to remote

resources through `CacheAwareExternalResourceAccessor`, reduce the number of remote calls in case several

projects are resolved in parallel: metadata loader honors the contract of not downloading the same

resource (`maven-metadata.xml`) concurrently.

    • -4
    • +16
    ./MavenSnapshotResolveIntegrationTest.groovy
  1. … 21 more files in changeset.
Use doLast instead of left shift operator

Made this change in preparation for deprecating the left shift operator.

+review REVIEW-6236

    • -9
    • +13
    ./MavenSnapshotResolveIntegrationTest.groovy
  1. … 163 more files in changeset.
Make integration test respect @NotYetImplemented

When the exception is thrown from a rule

@NotYetImplemented does not work.

    • -0
    • +2
    ./MavenSnapshotResolveIntegrationTest.groovy
Add an integration test for cacheChangingModulesFor and inherited configurations

GRADLE-3524

    • -1
    • +64
    ./MavenSnapshotResolveIntegrationTest.groovy