MavenPublishMultiProjectIntegTest.groovy

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Rename @FailsWithInstantExecution to @ToBeFixedForInstantExecution

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

    • -11
    • +11
    ./MavenPublishMultiProjectIntegTest.groovy
  1. … 872 more files in changeset.
Annotate integ tests failing with instant execution in :maven

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

    • -0
    • +11
    ./MavenPublishMultiProjectIntegTest.groovy
  1. … 39 more files in changeset.
Annotate integ tests failing with instant execution in :maven

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

    • -0
    • +11
    ./MavenPublishMultiProjectIntegTest.groovy
  1. … 39 more files in changeset.
Do not define scope for dependencyManagement entries

The semantics between the configuration of a constraint in Gradle and the scope

of a declaration in dependencyManagement in Maven are fundamentally

different.

Given this, Gradle will no longer attempt to define a scope for

dependencyManagement entries when creating POM files.

The only exception is the import scope as it carries special meaning.

Fixes #10878

    • -1
    • +1
    ./MavenPublishMultiProjectIntegTest.groovy
  1. … 4 more files in changeset.
Do not define scope for dependencyManagement entries

The semantics between the scope of a constraint in Gradle and the scope

of a declaration in dependencyManagement in Maven are fundamentally

different.

Given this, Gradle will no longer attempt to define a scope for

dependencyManagement entries when creating POM files.

The only exception is the import scope as it carries special meaning.

Fixes #10878

    • -1
    • +1
    ./MavenPublishMultiProjectIntegTest.groovy
  1. … 4 more files in changeset.
Do not define scope for dependencyManagement entries

The semantics between the configuration of a constraint in Gradle and the scope

of a declaration in dependencyManagement in Maven are fundamentally

different.

Given this, Gradle will no longer attempt to define a scope for

dependencyManagement entries when creating POM files.

The only exception is the import scope as it carries special meaning.

Fixes #10878

    • -1
    • +1
    ./MavenPublishMultiProjectIntegTest.groovy
  1. … 4 more files in changeset.
Do not define scope for dependencyManagement entries

The semantics between the configuration of a constraint in Gradle and the scope

of a declaration in dependencyManagement in Maven are fundamentally

different.

Given this, Gradle will no longer attempt to define a scope for

dependencyManagement entries when creating POM files.

The only exception is the import scope as it carries special meaning.

Fixes #10878

    • -1
    • +1
    ./MavenPublishMultiProjectIntegTest.groovy
  1. … 4 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

    • -1
    • +1
    ./MavenPublishMultiProjectIntegTest.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

    • -1
    • +1
    ./MavenPublishMultiProjectIntegTest.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

    • -1
    • +1
    ./MavenPublishMultiProjectIntegTest.groovy
  1. … 11 more files in changeset.
Deprecate the maven/ivy plugins

This commit introduces a deprecation warning for the `maven` plugin.

Because there's no such thing as an `ivy` plugin, we also deprecate

the _use_ of the `uploadArchives` task, which corresponds to uploading

with `ivy`, but is defined in the `base` plugin that we cannot

deprecate.

    • -0
    • +5
    ./MavenPublishMultiProjectIntegTest.groovy
  1. … 15 more files in changeset.
Deprecate the maven/ivy plugins

This commit introduces a deprecation warning for the `maven` plugin.

Because there's no such thing as an `ivy` plugin, we also deprecate

the _use_ of the `uploadArchives` task, which corresponds to uploading

with `ivy`, but is defined in the `base` plugin that we cannot

deprecate.

    • -0
    • +5
    ./MavenPublishMultiProjectIntegTest.groovy
  1. … 15 more files in changeset.
Let maven-publish tests not use deprecated configurations

    • -11
    • +11
    ./MavenPublishMultiProjectIntegTest.groovy
  1. … 8 more files in changeset.
Let maven-publish tests not use deprecated configurations

    • -11
    • +11
    ./MavenPublishMultiProjectIntegTest.groovy
  1. … 8 more files in changeset.
Let maven-publish tests not use deprecated configurations

    • -11
    • +11
    ./MavenPublishMultiProjectIntegTest.groovy
  1. … 8 more files in changeset.
Fix invalid lazy field check

When looking at variants, the code was only doing a null check. But that

is not valid as the field, lazily initialised, really should be check to

be an empty collection.

Fixes #8845

    • -7
    • +12
    ./MavenPublishMultiProjectIntegTest.groovy
  1. … 1 more file in changeset.
Use public API to publish Java Platforms

Follow-up to #8399

    • -1
    • +1
    ./MavenPublishMultiProjectIntegTest.groovy
  1. … 4 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.

    • -2
    • +2
    ./MavenPublishMultiProjectIntegTest.groovy
  1. … 57 more files in changeset.
Deprecate `JavaLibrary` in favor of public API

This commit makes use of the newly introduced software component

factory to support publishing of Java components using a public

API only.

There are a few consequences to this change, mostly around Gradle

metadata:

- variants `api` and `runtime` are now named `apiElements` and

`runtimeElements`

- it is no longer possible to warn the user when publishing a

variant without capability. This might change later if we decide

to _always_ publish capabilities (and optimize on read)

    • -2
    • +2
    ./MavenPublishMultiProjectIntegTest.groovy
  1. … 22 more files in changeset.
Enable multi module Java platform test

Now that we have the `java-platform` plugin, the test can be enabled

back and the proper behaviour asserted.

    • -8
    • +21
    ./MavenPublishMultiProjectIntegTest.groovy
  1. … 1 more file in changeset.
Setup new test for using local m2

    • -8
    • +1
    ./MavenPublishMultiProjectIntegTest.groovy
Polish integration test

    • -55
    • +45
    ./MavenPublishMultiProjectIntegTest.groovy
  1. … 1 more file in changeset.
Guard concurrent project modification during POM dependencies conversion

    • -0
    • +75
    ./MavenPublishMultiProjectIntegTest.groovy
  1. … 1 more file in changeset.
Import POM files as different variants

This commit implements solution 6 of #4422, by importing POM files

using different variants. By default, a POM file will be imported

as 6 different variants:

- 2 libraries (runtime and compile)

- 4 platforms (runtime and compile, regular and enforced)

This implies that a dependency on a BOM will now be intepreted as

a dependency on a library, whereas a dependency on a BOM expressed

using the `platform(...)` or `enforcedPlatform(...)` methods will

be interpreted as importing the platform component published at

the same coordinates.

This commit doesn't remove optional dependencies for Maven, but

reimplements how the dependencies are shuffled in different variants.

The dependencies found in a dependency management block are no

longer considered optional. Instead, they are properly marked as

constraints. However, they are only visible if using the experimental

flag, **and** using the platform variant.

    • -0
    • +2
    ./MavenPublishMultiProjectIntegTest.groovy
  1. … 31 more files in changeset.
Allow dependencies on a project with auxiliary publications

Users commonly publish their test fixtures alongside the main

component. Until now, depending on such a project would result

in an error during publishing, saying the Gradle can't decide

which of the publication coordinates to depend on.

Ideally we would model test fixtures as a first-class component

or provide an extensible API for users to define their own components

and their relationship. But to unblock this very common use case

quickly we decided to use a simple heuristic for now:

If a project only has one publication with a component, that publication

is the one we use when generating dependency declarations. The other

non-component publications are assumed to be auxiliary.

    • -1
    • +20
    ./MavenPublishMultiProjectIntegTest.groovy
  1. … 3 more files in changeset.
Remove model rules from maven-publish plugin

    • -2
    • +2
    ./MavenPublishMultiProjectIntegTest.groovy
  1. … 5 more files in changeset.
Make MavenPublication.from(SoftwareComponent) lazy

This prevents the software component from being read too early,

e.g. when configuring signing.

Previously any access of a publication resulted in the component

being read and any further modifications to it being ignored.

This is also a prerequisity for removing DeferredConfigurable.

    • -1
    • +0
    ./MavenPublishMultiProjectIntegTest.groovy
  1. … 5 more files in changeset.
Changed the 'swiftpm-export' plugin to reuse the same service to map a project dependency to a Swift PM target, as is used by the other publishing plugins to map a project dependency to a GAV.

    • -1
    • +1
    ./MavenPublishMultiProjectIntegTest.groovy
  1. … 19 more files in changeset.
Changed the mapping from project dependency to a GAV so that it does not use any types from the new publishing plugins, and is so decoupled from these plugins.

    • -3
    • +3
    ./MavenPublishMultiProjectIntegTest.groovy
  1. … 9 more files in changeset.
Update tests for constraints published to POM

- Verify <dependencyManagement> elements published to POM files

- Update tests to demonstrate that resolution with Maven metadata is now

more similar to resolution with Gradle metadata.

    • -11
    • +6
    ./MavenPublishMultiProjectIntegTest.groovy
  1. … 4 more files in changeset.