Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Introduce new metadata marker for Gradle 6 (#11109)

See: https://github.com/gradle/gradle/issues/11105

  1. … 14 more files in changeset.
Introduce new metadata marker for Gradle 6

See: https://github.com/gradle/gradle/issues/11105

  1. … 14 more files in changeset.
Introduce new metadata marker for Gradle 6

See: https://github.com/gradle/gradle/issues/11105

  1. … 14 more files in changeset.
Introduce new metadata marker for Gradle 6

See: https://github.com/gradle/gradle/issues/11105

  1. … 11 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. … 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. … 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. … 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. … 4 more files in changeset.
Fix resolved versions of substituted dependencies

This commit fixes an inconsistency when publishing resolved

versions of a component. If that component happens to be

substituted, which would be strange for a first level dependency

but nevertheless possible, then we wouldn't find the target

module in the resolution result, and the outcome would be that

POM/IVY/Gradle Module metadata files would all have an empty

version for a substituted dependency.

With the change, we will now also look for dependencies in

the resolution result, and if one matches the original dependency

coordinates, then we use its resolved component as the result.

This allows us to _substitute_ the result with complete coordinates

in the metadata files.

Fixes nebula-plugins/gradle-nebula-integration#62

  1. … 12 more files in changeset.
Fix resolved versions of substituted dependencies

This commit fixes an inconsistency when publishing resolved

versions of a component. If that component happens to be

substituted, which would be strange for a first level dependency

but nevertheless possible, then we wouldn't find the target

module in the resolution result, and the outcome would be that

POM/IVY/Gradle Module metadata files would all have an empty

version for a substituted dependency.

With the change, we will now also look for dependencies in

the resolution result, and if one matches the original dependency

coordinates, then we use its resolved component as the result.

This allows us to _substitute_ the result with complete coordinates

in the metadata files.

Fixes nebula-plugins/gradle-nebula-integration#62

  1. … 12 more files in changeset.
Fix resolved versions of substituted dependencies

This commit fixes an inconsistency when publishing resolved

versions of a component. If that component happens to be

substituted, which would be strange for a first level dependency

but nevertheless possible, then we wouldn't find the target

module in the resolution result, and the outcome would be that

POM/IVY/Gradle Module metadata files would all have an empty

version for a substituted dependency.

With the change, we will now also look for dependencies in

the resolution result, and if one matches the original dependency

coordinates, then we use its resolved component as the result.

This allows us to _substitute_ the result with complete coordinates

in the metadata files.

Fixes nebula-plugins/gradle-nebula-integration#62

  1. … 12 more files in changeset.
Apply `Anonymous type can be replaced with lambda` inspection the whole project

  1. … 666 more files in changeset.
Apply `Explicit type can be replaced with <>` inspection the whole project

  1. … 909 more files in changeset.
Organize imports

  1. … 339 more files in changeset.
Replace anonymous classes with lambdas

  1. … 711 more files in changeset.
Replace anonymous classes with lambdas

  1. … 695 more files in changeset.
Remove synthetic accessors for internal private symbol references

  1. … 902 more files in changeset.
Remove synthetic accessors for internal private symbol references

  1. … 902 more files in changeset.
Remove synthetic accessors for internal private symbol references

  1. … 890 more files in changeset.
Remove synthetic accessors for internal private symbol references

  1. … 897 more files in changeset.
Remove synthetic accessors for internal private symbol references

  1. … 902 more files in changeset.
Remove synthetic accessors for internal private symbol references

  1. … 902 more files in changeset.
Add missing @Override to all modules

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

  1. … 1005 more files in changeset.
Add missing @Override to all modules

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

  1. … 999 more files in changeset.
Fix Gradle Module Metadata disappearing

This commit fixes an issue where using `withXml` would

erase the Gradle Module Metadata marker from generated

POM or IVY files.

This is fixed by having the marker being a finalizer,

rather than an initial step.

  1. … 4 more files in changeset.
Fix Gradle Module Metadata disappearing

This commit fixes an issue where using `withXml` would

erase the Gradle Module Metadata marker from generated

POM or IVY files.

This is fixed by having the marker being a finalizer,

rather than an initial step.

  1. … 4 more files in changeset.
Fix Gradle Module Metadata disappearing

This commit fixes an issue where using `withXml` would

erase the Gradle Module Metadata marker from generated

POM or IVY files.

This is fixed by having the marker being a finalizer,

rather than an initial step.

  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.

  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)

  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.