IvyGradleModuleMetadataPublishIntegrationTest.groovy

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Add validation at publication time

This commit introduces validation when generating Gradle

Module Metadata:

- check that there's at least one variant published

- each variant must have at least one attribute

- there shouldn't be duplicate variant names

- each variant must have a different (attributes,capabilities)

combination

Closes #10736

    • -15
    • +217
    ./IvyGradleModuleMetadataPublishIntegrationTest.groovy
  1. … 11 more files in changeset.
Add validation at publication time

This commit introduces validation when generating Gradle

Module Metadata:

- check that there's at least one variant published

- each variant must have at least one attribute

- there shouldn't be duplicate variant names

- each variant must have a different (attributes,capabilities)

combination

Closes #10736

    • -15
    • +217
    ./IvyGradleModuleMetadataPublishIntegrationTest.groovy
  1. … 11 more files in changeset.
Add validation at publication time

This commit introduces validation when generating Gradle

Module Metadata:

- check that there's at least one variant published

- each variant must have at least one attribute

- there shouldn't be duplicate variant names

- each variant must have a different (attributes,capabilities)

combination

Closes #10736

    • -15
    • +217
    ./IvyGradleModuleMetadataPublishIntegrationTest.groovy
  1. … 11 more files in changeset.
Rename inheritStrictVersions() -> endorseStrictVersions() (#10755)

This name change more clearly communicates the semantics of the

feature from a users point of view.

This commit also removes all mentions of 'inheriting' AND 'forSubgraph'.

There have been some leftovers in documentation/comments that

would have been misleading in the future. To make sure we catch all,

this also updates all variable/method/package names.

    • -3
    • +3
    ./IvyGradleModuleMetadataPublishIntegrationTest.groovy
  1. … 70 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.

    • -3
    • +3
    ./IvyGradleModuleMetadataPublishIntegrationTest.groovy
  1. … 70 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.

    • -3
    • +3
    ./IvyGradleModuleMetadataPublishIntegrationTest.groovy
  1. … 70 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.

    • -3
    • +3
    ./IvyGradleModuleMetadataPublishIntegrationTest.groovy
  1. … 70 more files in changeset.
Updates to terminology for clarity

- `inheritStrictConstraints` -> `inheritStrictVersions`

- `notInheritStrictConstraints` -> `doNotInheritStrictVersions`

    • -3
    • +3
    ./IvyGradleModuleMetadataPublishIntegrationTest.groovy
  1. … 31 more files in changeset.
Updates to terminology for clarity

- `inheritStrictConstraints` -> `inheritStrictVersions`

- `notInheritStrictConstraints` -> `doNotInheritStrictVersions`

    • -3
    • +3
    ./IvyGradleModuleMetadataPublishIntegrationTest.groovy
  1. … 31 more files in changeset.
Updates to terminology for clarity

- `inheritStrictConstraints` -> `inheritStrictVersions`

- `notInheritStrictConstraints` -> `doNotInheritStrictVersions`

    • -3
    • +3
    ./IvyGradleModuleMetadataPublishIntegrationTest.groovy
  1. … 31 more files in changeset.
Updates to terminology for clarity

- `inheritStrictConstraints` -> `inheritStrictVersions`

- `notInheritStrictConstraints` -> `doNotInheritStrictVersions`

    • -3
    • +3
    ./IvyGradleModuleMetadataPublishIntegrationTest.groovy
  1. … 31 more files in changeset.
Updates to terminology for clarity

- `inheritStrictConstraints` -> `inheritStrictVersions`

- `notInheritStrictConstraints` -> `doNotInheritStrictVersions`

    • -3
    • +3
    ./IvyGradleModuleMetadataPublishIntegrationTest.groovy
  1. … 31 more files in changeset.
Updates to terminology for clarity

- `inheritStrictConstraints` -> `inheritStrictVersions`

- `notInheritStrictConstraints` -> `doNotInheritStrictVersions`

    • -3
    • +3
    ./IvyGradleModuleMetadataPublishIntegrationTest.groovy
  1. … 30 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).

    • -13
    • +10
    ./IvyGradleModuleMetadataPublishIntegrationTest.groovy
  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).

    • -13
    • +10
    ./IvyGradleModuleMetadataPublishIntegrationTest.groovy
  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).

    • -13
    • +10
    ./IvyGradleModuleMetadataPublishIntegrationTest.groovy
  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).

    • -13
    • +10
    ./IvyGradleModuleMetadataPublishIntegrationTest.groovy
  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).

    • -13
    • +10
    ./IvyGradleModuleMetadataPublishIntegrationTest.groovy
  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).

    • -13
    • +10
    ./IvyGradleModuleMetadataPublishIntegrationTest.groovy
  1. … 77 more files in changeset.
Adjust tests and samples to new publishing default behavior

    • -12
    • +5
    ./IvyGradleModuleMetadataPublishIntegrationTest.groovy
  1. … 43 more files in changeset.
Remove 'experimental' variant from dependency resolution tests

With the 'GRADLE_METADATA' feature preview gone, we now only have

two dimensions of variation to test:

(1) Ivy or Maven repository?

(2) Gradle metadata available - in addition to pom or ivy - or not?

If Gradle 6+ was used for publishing, Gradle metadata is most likely

available and the pom/ivy file contains the corresponding marker.

If an older Gradle version (or Maven/Ivy) was used for publishing,

Gradle metadata is not available and there is also no marker in the

other metadata file.

    • -1
    • +0
    ./IvyGradleModuleMetadataPublishIntegrationTest.groovy
  1. … 32 more files in changeset.
Remove 'experimental' variant from dependency resolution tests

With the 'GRADLE_METADATA' feature preview gone, we now only have

two dimensions of variation to test:

(1) Ivy or Maven repository?

(2) Gradle metadata available - in addition to pom or ivy - or not?

If Gradle 6+ was used for publishing, Gradle metadata is most likely

available and the pom/ivy file contains the corresponding marker.

If an older Gradle version (or Maven/Ivy) was used for publishing,

Gradle metadata is not available and there is also no marker in the

other metadata file.

    • -1
    • +0
    ./IvyGradleModuleMetadataPublishIntegrationTest.groovy
  1. … 32 more files in changeset.
Remove 'experimental' variant from dependency resolution tests

With the 'GRADLE_METADATA' feature preview gone, we now only have

two dimensions of variation to test:

(1) Ivy or Maven repository?

(2) Gradle metadata available - in addition to pom or ivy - or not?

If Gradle 6+ was used for publishing, Gradle metadata is most likely

available and the pom/ivy file contains the corresponding marker.

If an older Gradle version (or Maven/Ivy) was used for publishing,

Gradle metadata is not available and there is also no marker in the

other metadata file.

    • -1
    • +0
    ./IvyGradleModuleMetadataPublishIntegrationTest.groovy
  1. … 32 more files in changeset.
Adjust tests following Gradle Module Metadata feature preview removal

    • -11
    • +5
    ./IvyGradleModuleMetadataPublishIntegrationTest.groovy
  1. … 29 more files in changeset.
Adjust tests following Gradle Module Metadata feature preview removal

    • -11
    • +5
    ./IvyGradleModuleMetadataPublishIntegrationTest.groovy
  1. … 29 more files in changeset.
Adjust tests following Gradle Module Metadata feature preview removal

    • -11
    • +5
    ./IvyGradleModuleMetadataPublishIntegrationTest.groovy
  1. … 29 more files in changeset.
Add 'inheritConstraints' to Gradle Module Metadata

Adds test coverage for consuming and publishing.

    • -0
    • +84
    ./IvyGradleModuleMetadataPublishIntegrationTest.groovy
  1. … 12 more files in changeset.
Implement Gradle metadata marker in published pom/ivy files

This commit implements a performance optimization for Gradle metadata.

Given that today there's no library published in any repository with

Gradle metadata, it's much more likely to find a POM (or Ivy) metadata

file for an external dependency, rather than a Gradle metadata file.

If we decided to add `gradleMetadata()` sources by default to all

repositories, then we would probably introduce a performance regression

to a lot of builds, because we would first try to get Gradle metadata,

then fail, and search for POM/Ivy files.

To avoid this, whenever a library is going to be published with Gradle

metadata, we will introduce a _marker_ in the published POM or Ivy

file. When Gradle _resolves_ such a dependency, it will parse the POM

file and look for the marker. If it finds it, then it will _redirect_

to use Gradle metadata instead. This means that when Gradle metadata is

present, we will pay the price of looking for a POM or Ivy file first,

start parsing, only to discover we should parse Gradle metadata. This

should be ok in the beginning, knowing that if `gradleMetadata()` is

added, then we would systematically look at Gradle metadata first.

This means that this is a _temporary_ solution, until Gradle metadata

becomes widespread. So "temporary" should be understood as several

months, if not years.

The marker introduced in POM and Ivy files is _neutral_ for both Ivy

and Maven. By this we mean that it uses an XML comment. While not super

nice, we couldn't use a custom namespace because both Ivy and Maven

fail when parsing this. Properties were considered too, but Ivy doesn't

support them so for consistency both models use comments.

It's worth noting that we will still _completely parse_ the POM or Ivy

descriptor. It's a waste of time, but it helps in case we find a marker

but that for some reason the Gradle metadata file is absent. In this

case we fallback on the model we found.

This change also introduces a change in the semantics of the incubating

metadata sources API: those should be considered _hints_, and not strong

statements anymore.

Finally, should a producer want to avoid publishing Gradle metadata,

it's now possible to disable the task that creates the metadata file.

    • -0
    • +52
    ./IvyGradleModuleMetadataPublishIntegrationTest.groovy
  1. … 57 more files in changeset.
Do not bake in assumptions into Gradle metadata parser/writer

This commit reworks the Gradle metadata parser and writer, so

that they don't assume any particular correspondance between

prefer/strictly/reject. Before this, we would for example have

removed the "prefer" constraint when publishing a dependency

which had a "strictly" set.

    • -1
    • +1
    ./IvyGradleModuleMetadataPublishIntegrationTest.groovy
  1. … 6 more files in changeset.
Avoid publishing redundant constraint information in module metadata

    • -4
    • +5
    ./IvyGradleModuleMetadataPublishIntegrationTest.groovy
  1. … 9 more files in changeset.