MavenGradleModuleMetadataPublishIntegrationTest.groovy

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Annotated new test since merging master to be fixed for instant execution

Signed-off-by: Paul Merlin <paul@gradle.com>

    • -0
    • +1
    ./MavenGradleModuleMetadataPublishIntegrationTest.groovy
Rename @FailsWithInstantExecution to @ToBeFixedForInstantExecution

Signed-off-by: Paul Merlin <paul@gradle.com>

    • -15
    • +15
    ./MavenGradleModuleMetadataPublishIntegrationTest.groovy
  1. … 872 more files in changeset.
Merge branch 'master' into eskatos/ie/instantIntegTest-enable

    • -42
    • +87
    ./MavenGradleModuleMetadataPublishIntegrationTest.groovy
  1. … 8 more files in changeset.
Gradle module metadata: forbid no version at all

With this change, it becomes illegal to create a Gradle Module Metadata

file that has depedencies or constraints declared without any version at

all across all variants.

    • -42
    • +87
    ./MavenGradleModuleMetadataPublishIntegrationTest.groovy
  1. … 5 more files in changeset.
Annotate integ tests failing with instant execution in :maven

Signed-off-by: Paul Merlin <paul@gradle.com>

    • -0
    • +15
    ./MavenGradleModuleMetadataPublishIntegrationTest.groovy
  1. … 39 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

    • -12
    • +211
    ./MavenGradleModuleMetadataPublishIntegrationTest.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
    ./MavenGradleModuleMetadataPublishIntegrationTest.groovy
  1. … 70 more files in changeset.
Updates to terminology for clarity

- `inheritStrictConstraints` -> `inheritStrictVersions`

- `notInheritStrictConstraints` -> `doNotInheritStrictVersions`

    • -3
    • +3
    ./MavenGradleModuleMetadataPublishIntegrationTest.groovy
  1. … 31 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
    ./MavenGradleModuleMetadataPublishIntegrationTest.groovy
  1. … 77 more files in changeset.
Adjust tests and samples to new publishing default behavior

    • -12
    • +4
    ./MavenGradleModuleMetadataPublishIntegrationTest.groovy
  1. … 43 more files in changeset.
Add 'inheritConstraints' to Gradle Module Metadata

Adds test coverage for consuming and publishing.

    • -0
    • +84
    ./MavenGradleModuleMetadataPublishIntegrationTest.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
    ./MavenGradleModuleMetadataPublishIntegrationTest.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
    ./MavenGradleModuleMetadataPublishIntegrationTest.groovy
  1. … 6 more files in changeset.
Use `require` instead of `prefer` in more tests

    • -3
    • +2
    ./MavenGradleModuleMetadataPublishIntegrationTest.groovy
  1. … 11 more files in changeset.
Avoid publishing redundant constraint information in module metadata

    • -3
    • +5
    ./MavenGradleModuleMetadataPublishIntegrationTest.groovy
  1. … 9 more files in changeset.
Separate 'prefer' and 'require' in dependency versions

When we introduced the ability to declare a 'preferred' version on

a dependency declaration, this was implemented such that declaring

a "required" dependency version using `org:foo:1.0` was effectively

the same as declaring a "preferred" version `org:foo { prefer '1.0' }`.

In order to differentiate between the behaviour of required and

preferred dependency versions, this commit introduces a separate

model for these constraint types. This model is published to

Gradle `.module` metadata files, and is retained internally

throughout dependency resolution.

At this stage, the behaviour of required and preferred versions

is identical. A later commit will introduce the behavioural

difference.

    • -3
    • +16
    ./MavenGradleModuleMetadataPublishIntegrationTest.groovy
  1. … 36 more files in changeset.
Retain separate versions for 'strictly' and 'prefers'

Previously, a `strictly` version constraint was translated into a separate

'prefer' and 'reject' constraint: this is how it was processed internally,

as well as how it was represented in a `.module` file.

With this change, strict version constraints are logically retained as a

first class version constraint:

- `.module` files can have versions declared with `strictly`

- Strict constraints are only translated to a reject version selector

as part of resolution (not when parsing the constraint)

    • -1
    • +3
    ./MavenGradleModuleMetadataPublishIntegrationTest.groovy
  1. … 25 more files in changeset.
Fix publishing integTests for changed reject syntax

    • -1
    • +1
    ./MavenGradleModuleMetadataPublishIntegrationTest.groovy
  1. … 3 more files in changeset.
Revert changes from PR5628

This reverts the following commits:

10a25358953dfb28b09cf04356945517d5cc560e

54d19a74ab2d29673219d9c6d27388b93c55eada

d0eb19dbf28df1a108742ba177eda56301e1fab4

dcf5f65b49db17fb625ecab7498b060ab8191b9b

99847ad25f9e0ab7b1f65beb976dcb59cbadd1b9

f2f412141e1ab29e0cfafc72fd962ae645508720

99b45c8d7f0e94d2d41c43c731ca1329d6f07606

    • -1
    • +1
    ./MavenGradleModuleMetadataPublishIntegrationTest.groovy
  1. … 40 more files in changeset.
Fix publishing integTests for changed reject syntax

    • -1
    • +1
    ./MavenGradleModuleMetadataPublishIntegrationTest.groovy
  1. … 3 more files in changeset.
Fix publishing integTests for changed reject syntax

    • -1
    • +1
    ./MavenGradleModuleMetadataPublishIntegrationTest.groovy
  1. … 3 more files in changeset.
Add test coverage for publishing dependency attributes

This commit adds test coverage for the `maven-publish` and `ivy-publish` plugins,

making sure that the dependency attributes are actually published in Gradle metadata.

Closes gradle/gradle-private#1189

    • -0
    • +63
    ./MavenGradleModuleMetadataPublishIntegrationTest.groovy
  1. … 4 more files in changeset.
Publish configuration-wide excludes in Ivy metadata

Resolves #4356.

    • -0
    • +1
    ./MavenGradleModuleMetadataPublishIntegrationTest.groovy
  1. … 17 more files in changeset.
Rename `CapabilitiesDescriptor` to `Capabilities`

... and `getCapababilitiesMetadata()` to `getCapabilities()` for consistency.

    • -1
    • +1
    ./MavenGradleModuleMetadataPublishIntegrationTest.groovy
  1. … 36 more files in changeset.
Publish capabilities to Ivy/Maven repositories

This commit makes sure that capabilities can be published to Maven or Ivy repositories.

By published, we only mean using Gradle metadata: capabilities are a Gradle-only feature,

so there's no equivalent to be published in a `pom.xml` or `ivy.xml` file.

    • -0
    • +46
    ./MavenGradleModuleMetadataPublishIntegrationTest.groovy
  1. … 15 more files in changeset.
Separate Dependency Constraint and Dependency declarations (#4255)

The interfaces for declaring these two different things were

coupled in the initial implementation - to reuse all functionality

based on the Dependency interface directly. This interface is used

internally to pass dependency declarations through the resolution

process. However, this is only due to remembering the first

level dependencies for the "old" results API

(Configuration.resolvedConfiguration()).

These implementation specifics should not bleed into the API.

A dependency declaration defines a *requirement*:

I require module/project X

A dependency constraint defines a *constraint*:

If I must use X, I can only work with versions matching the constraint

Only if we look at external dependencies, constraints and external dependencies

share the ability to declare a *version constraint*. Therefore, both now

extend ModuleVersionSelector.

Now, dependency constraints are removed as "first level dependencies"

from the result. This is fine as the dependency itself is still in the

result graph - when there is a constraint, there is always at least one other

edge.

    • -2
    • +2
    ./MavenGradleModuleMetadataPublishIntegrationTest.groovy
  1. … 33 more files in changeset.
Rename setter for reasons in the dsl to 'because'

This is more consistent in the DSL for two reasons:

1) Other places (rules) where reasons are supported already use

'because ...'

2) Other DSL constructs such as version constraints use a similar

wording. For example, now you can write:

compile('com.google.collections:google-collections') {

version { rejectAll() }

because 'Guava replaces google collections'

}

    • -2
    • +2
    ./MavenGradleModuleMetadataPublishIntegrationTest.groovy
  1. … 11 more files in changeset.
Make sure that dependency (constraint) reasons can be published

Signed-off-by: Cedric Champeau <cedric@gradle.com>

    • -0
    • +57
    ./MavenGradleModuleMetadataPublishIntegrationTest.groovy
  1. … 7 more files in changeset.
Add integration tests for publishing and resolving rejected dependency versions

    • -0
    • +58
    ./MavenGradleModuleMetadataPublishIntegrationTest.groovy
  1. … 3 more files in changeset.
Publish dependency constraints to Gradle module metadata

    • -0
    • +51
    ./MavenGradleModuleMetadataPublishIntegrationTest.groovy
  1. … 12 more files in changeset.