artifacts

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Revert "Revert "Merge branch 'release'""

This reverts commit 67b8bb8f18f854f45a2f5ec52cc9c8a25981e2f2.

This restores the merge attempt from earlier.

  1. … 65 more files in changeset.
Add missing @since

Revert "Merge branch 'release'"

This reverts commit c7fdc455dcb9a8016af0ae9bc8b4c43fde1e2d06, reversing

changes made to 9f70d52b74dbc8c71381781b6c155474031b3cf8.

The changes need a wrapper as there are API changes. Reverting for now.

  1. … 65 more files in changeset.
Support variant selection in capability conflict resolution (#10973)

A conflict can also occur between two variants of the same component.

This gives access to the variant name in the selection rule and

evicts nodes that represent the not-selected variant.

    • -0
    • +39
    ./ComponentVariantIdentifier.java
  1. … 12 more files in changeset.
Support variant selection in capability conflict resolution

A conflict can also occur between two variants of the same component.

This gives access to the variant name in the selection rule and

evicts nodes that represent the not-selected variant.

  1. … 12 more files in changeset.
Support variant selection in capability conflict resolution

A conflict can also occur between two variants of the same component.

This gives access to the variant name in the selection rule and

evicts nodes that represent the not-selected variant.

    • -0
    • +39
    ./ComponentVariantIdentifier.java
  1. … 11 more files in changeset.
Add `failOnNonReproducibleResolution`

This method is a short-hand notation to disable both use

of dynamic and changing versions.

  1. … 8 more files in changeset.
Add `failOnNonReproducibleResolution`

This method is a short-hand notation to disable both use

of dynamic and changing versions.

  1. … 8 more files in changeset.
Add support for failing on changing versions

This commit adds the `failOnChangingVersions()` method on

the resolution strategy, which will make the build fail as

soon as a changing version is detected.

This is useful to prevent, for example, snapshots from

appearing in a dependency graph.

  1. … 5 more files in changeset.
Add support for failing on changing versions

This commit adds the `failOnChangingVersions()` method on

the resolution strategy, which will make the build fail as

soon as a changing version is detected.

This is useful to prevent, for example, snapshots from

appearing in a dependency graph.

  1. … 5 more files in changeset.
Introduce `failOnDynamicVersion`

This commit introduces a new dependency graph validation mode,

which will make sure that if dynamic versions are found in the

graph, then either they are superceded by another version (they

don't participate in selection) or the build should fail.

This means that, for example, if a version selector uses a

version range `[1.0, 2.0[`, the build will fail because in a

subsequent build the resolution may change.

However, if there are two selectors participating, say

`[1.0, 2.0[` and `1.5`, then we choose `1.5` because this version

is within the range. Even if newer versions are released, we

would _not_ change the resolution result.

  1. … 8 more files in changeset.
Introduce `failOnDynamicVersion`

This commit introduces a new dependency graph validation mode,

which will make sure that if dynamic versions are found in the

graph, then either they are superceded by another version (they

don't participate in selection) or the build should fail.

This means that, for example, if a version selector uses a

version range `[1.0, 2.0[`, the build will fail because in a

subsequent build the resolution may change.

However, if there are two selectors participating, say

`[1.0, 2.0[` and `1.5`, then we choose `1.5` because this version

is within the range. Even if newer versions are released, we

would _not_ change the resolution result.

  1. … 8 more files in changeset.
De-incubate latest dependency management APIs for 6.0 (#10886)

These are APIs that complete features which are fully implemented and

de-incubated in Gradle 6.

  1. … 6 more files in changeset.
De-incubate latest dependency management APIs for 6.0

These are APIs that complete features which are fully implemented and

de-incubated in Gradle 6.

  1. … 6 more files in changeset.
Fixed wording in javadoc 'inherited' -> 'endorsed'

Explicitly expect auto-tested samples to use deprecatied APIs

  1. … 3 more files in changeset.
deactivateDependencyLocking: add Incubating annotation

Signed-off-by: Roberto Perez Alcolea <rperezalcolea@netflix.com>

Surface allowInsecureProtocol in DSL reference

    • -24
    • +6
    ./repositories/UrlArtifactRepository.java
  1. … 5 more files in changeset.
Add support for deactivateDependencyLocking to disable locking on configurations

Signed-off-by: Roberto Perez Alcolea <rperezalcolea@netflix.com>

    • -0
    • +11
    ./dsl/DependencyLockingHandler.java
  1. … 11 more files in changeset.
Rewrite section on component metadata rules (#10735)

The section was written when the very first version of rules was

introduced and since then only marginally updated.

This is a complete rewrite of the section focusing on explaining

all the metadata modeling features of Gradle Module Metadata

which can be utilized in rules to enrich existing metadata.

The features are described on using real-world use cases.

Related sections are also updated where applicable.

    • -28
    • +0
    ./dsl/ComponentMetadataHandler.java
  1. … 59 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.

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

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

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

  1. … 69 more files in changeset.
Fix errors in the single version description

  1. … 2 more files in changeset.
Fix errors in the single version description

  1. … 2 more files in changeset.
Rewrite section on component metadata rules

The section was written when the very first version of rules was

introduced and since then only marginally updated.

This is a complete rewrite of the section focusing on explaining

all the metadata modeling features of Gradle Module Metadata

which can be utilized in rules to enrich existing metadata.

The features are described on using real-world use cases.

Related sections are also updated where applicable.

    • -28
    • +0
    ./dsl/ComponentMetadataHandler.java
  1. … 57 more files in changeset.
Rewrite section on component metadata rules

The section was written when the very first version of rules was

introduced and since then only marginally updated.

This is a complete rewrite of the section focusing on explaining

all the metadata modeling features of Gradle Module Metadata

which can be utilized in rules to enrich existing metadata.

The features are described on using real-world use cases.

Related sections are also updated where applicable.

    • -28
    • +0
    ./dsl/ComponentMetadataHandler.java
  1. … 57 more files in changeset.
Rewrite section on component metadata rules

The section was written when the very first version of rules was

introduced and since then only marginally updated.

This is a complete rewrite of the section focusing on explaining

all the metadata modeling features of Gradle Module Metadata

which can be utilized in rules to enrich existing metadata.

The features are described on using real-world use cases.

Related sections are also updated where applicable.

    • -28
    • +0
    ./dsl/ComponentMetadataHandler.java
  1. … 59 more files in changeset.
Rewrite of section on component metadata rules

The section was written when the very first version of rules was

introduced and since then only marginally updated.

This is a complete rewrite of the section focusing explaining

all the metadata modeling features of Gradle Module Metadata

which can be utilized in rules to complete existing metadata.

The features are described on using real-world use cases.

Related sections are also updated where applicable.

    • -28
    • +0
    ./dsl/ComponentMetadataHandler.java
  1. … 57 more files in changeset.