Clone Tools
  • last updated a few seconds ago
Constraints: committers
Constraints: files
Constraints: dates
Support more notations for `MavenPublication#artifact()`

Currently, there's no good way for a user to have a lazy artifact

provider, even if the producer is lazy (e.g, a `TaskProvider` or

a `Provider<RegularFile>`.

This commit fixes that by supporting more notations in the converter

and automatically using `LazyPublishArtifact` when a provider is


The lazy publish artifact now also supports more, in particular it

can accept any task as long as it provides a _single_ output file.

Fixes #7958

  1. … 3 more files in changeset.
Remove unnecessary mock setup from `DefaultMavenPublicationTest`

Simplify `DefaultMavenPublication`

By moving a little complexity to the test.

  1. … 1 more file in changeset.
Upgrade JUnit version (#12924)

Upgrade JUnit to 4.13, JUnit platform to 5.6.2

  1. … 331 more files in changeset.
When a strict `Property` is read, finalize all properties whose values are used to calculate the property's final value.

  1. … 42 more files in changeset.
Force AbstractTestDirectoryProvider to use Class (#12431)


This PR adds `className` to `AbstractTestDirectoryProvider` so there'll be no more `unknown-test-class`.

  1. … 402 more files in changeset.
Add `HasConfigurableValue.disallowUnsafeRead()` to allow plugins to switch lazy instances to 'strict' behaviour wrt reads.

In this commit, a strict `Property` disallows reads until the owning project's `afterEvaluate` starts. This is not implemented for `FileCollection` yet.

  1. … 35 more files in changeset.
Added integration tests to make sure retries happen for maven and ivy publication

Signed-off-by: Roberto Perez Alcolea <>

  1. … 6 more files in changeset.
Do not publish stale signature files

This commit fixes the publication of stale signature files:

prior to this change it was possible that a signature generated

in a previous build for a different artifact was uploaded even

if no signature was generated during the build, which would

lead to inconsistent publications.

In addition, it makes it an error to publish something which

doesn't have the main artifact created (or, at least up-to-date)

in this build. In other words, if the task which generates the

main artifact is disabled, it's an error to publish.

Other stale artifacts are going to be ignored.

Fixes #5136

  1. … 37 more files in changeset.
Introduce new metadata marker for Gradle 6 (#11109)


  1. … 14 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)


Closes #10736

  1. … 11 more files in changeset.
Skip publication of self referencing dependencies

When a dependency references the same module as the one being published

without any artifact information, it is skipped and thus not included in

the POM file.

Fixes #10429

  1. … 2 more files in changeset.
Refactor HTTP deprecation logic to use HttpRedirectVerifier

  1. … 60 more files in changeset.
Publish Gradle Module Metadata by default

  1. … 4 more files in changeset.
Transition some static methods to a global service, so the implementation can be contextualized.

  1. … 12 more files in changeset.
Inline org.gradle.testing.internal.util.Specification

  1. … 53 more files in changeset.
Move network utility to :dependencyManagement project

  1. … 4 more files in changeset.
Retry HTTP PUT when publishing with `maven-publish`

  1. … 3 more files in changeset.
Replace 'Matchers' with 'CoreMatchers'

So we do not require 'org.hamcrest:hamcrest-library' as additional

dependency anymore. Which was only available for most of the tests

because it leaked onto the test compile classpath.

  1. … 162 more files in changeset.
Avoid eager realization of publishing tasks

  1. … 9 more files in changeset.
Allow `maven-publish` with a POM that obtains group/version from parent POM

Fixes #6009

  1. … 2 more files in changeset.
Simplify use of `MavenNormalizedPublication`

  1. … 5 more files in changeset.
Adjust ValidatingMavenPublisherTest

Signed-off-by: Martin d'Anjou <>

Introduce DefaultMavenDeployRetrier unit tests

Signed-off-by: Roberto Perez Alcolea <>

  1. … 3 more files in changeset.
Update Category attribute to be typed

Adapt code to new typed attributes, dealing with coercible String values

when parsed from metadata and typed values when created inside a Gradle


  1. … 27 more files in changeset.
Rename category attribute

Attribute is now `org.gradle.category` and the constant is named


The removal of the "component" part of the name was to clarify to what

the category applies.

  1. … 26 more files in changeset.
Add task to publish all publications to a single Maven repository

Fixes #8509

  1. … 1 more file 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.

  1. … 56 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


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


- 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)

  1. … 22 more files in changeset.
Add support for customizing Maven POM properties (#8341)

Add support for customizing Maven POM properties

This was previously only possible by modifying the raw POM XML tree by

calling withXml. This change adds the possibility to set Maven POM

properties using a MapProperty<String, String>.

Resolves: #5739

  1. … 8 more files in changeset.