Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Remove `platform` dsl from constraint handler

These shortcuts define details of a dependency like attributes,

requested capabilities and 'endorse strict' status. These things

can not be defined on constraints. So these methods only cause

inconsistent behavior.

One can use constraints in combination with platforms like this to

control platform versions:

dependencies {

api platform("org:platform")

constraints {

api "org:platform:1.0"

}

}

    • -1
    • +0
    ./AbstractDependencyMetadataRulesTest.groovy
  1. … 11 more files in changeset.
Remove `platform` dsl from constraint handler

These shortcuts define details of a dependency like attributes,

requested capabilities and 'endorse strict' status. These things

can not be defined on constraints. So these methods only cause

inconsistent behavior.

One can use constraints in combination with platforms like this to

control platform versions:

dependencies {

api platform("org:platform")

constraints {

api "org:platform:1.0"

}

}

    • -1
    • +0
    ./AbstractDependencyMetadataRulesTest.groovy
  1. … 9 more files in changeset.
Remove `platform` dsl from constraint handler

These shortcuts define details of a dependency like attributes,

requested capabilities and 'endorse strict' status. These things

can not be defined on constraints. So these methods only cause

inconsistent behavior.

One can use constraints in combination with platforms like this to

control platform versions:

dependencies {

api platform("org:platform")

constraints {

api "org:platform:1.0"

}

}

    • -1
    • +0
    ./AbstractDependencyMetadataRulesTest.groovy
  1. … 12 more files in changeset.
Remove `platform` dsl from constraint handler

These shortcuts define details of a dependency like attributes,

requested capabilities and 'endorse strict' status. These things

can not be defined on constraints. So these methods only cause

inconsistent behavior.

One can use constraints in combination with platforms like this to

control platform versions:

dependencies {

api platform("org:platform")

constraints {

api "org:platform:1.0"

}

}

    • -1
    • +0
    ./AbstractDependencyMetadataRulesTest.groovy
  1. … 9 more files in changeset.
Fix NPE and tests

    • -0
    • +2
    ./AbstractDependencyMetadataRulesTest.groovy
    • -0
    • +1
    ./VariantFilesMetadataRulesTest.groovy
  1. … 5 more files in changeset.
Fix NPE and tests

    • -0
    • +2
    ./AbstractDependencyMetadataRulesTest.groovy
    • -0
    • +1
    ./VariantFilesMetadataRulesTest.groovy
  1. … 4 more files in changeset.
Use a different 'shadow capability' for enforced platform

This allows both 'regular' and 'enforced' platform of the same

component to be selected. In order to make this work, support

for projects having shadow capability needed to be added.

    • -0
    • +2
    ./AbstractDependencyMetadataRulesTest.groovy
    • -0
    • +1
    ./VariantFilesMetadataRulesTest.groovy
  1. … 11 more files in changeset.
Always apply all Category disambiguation rules

Before, parts of the platform disambiguation were only done when

using the 'java-platform' plugin. However, other consumers

may also require all rules (see #11091)

    • -1
    • +0
    ./AbstractDependencyMetadataRulesTest.groovy
    • -1
    • +0
    ./VariantFilesMetadataRulesTest.groovy
  1. … 5 more files in changeset.
Always apply all Category disambiguation rules

Before, parts of the platform disambiguation were only done when

using the 'java-platform' plugin. However, other consumers

may also require all rules (see #11091)

    • -1
    • +0
    ./AbstractDependencyMetadataRulesTest.groovy
    • -1
    • +0
    ./VariantFilesMetadataRulesTest.groovy
  1. … 5 more files in changeset.
Always apply all Category disambiguation rules in Java ecosystem

Before, parts of the platform disambiguation were only done when

using the 'java-platform' plugin. However, consumers using other

Java plugins may also require all rules (see #11091)

    • -1
    • +0
    ./AbstractDependencyMetadataRulesTest.groovy
    • -1
    • +0
    ./VariantFilesMetadataRulesTest.groovy
  1. … 4 more files in changeset.
Remove derived enforced-platform variants

Instead, implement them with strict versions for external modules.

    • -7
    • +1
    ./DefaultMavenModuleResolveMetadataTest.groovy
    • -2
    • +2
    ./VariantFilesMetadataRulesTest.groovy
  1. … 18 more files in changeset.
Remove derived enforced-platform variants

Instead, implement them with strict versions for external modules.

    • -7
    • +1
    ./DefaultMavenModuleResolveMetadataTest.groovy
    • -2
    • +2
    ./VariantFilesMetadataRulesTest.groovy
  1. … 18 more files in changeset.
Remove derived enforced-platform variants

Instead, implement them with strict versions for external modules.

    • -7
    • +1
    ./DefaultMavenModuleResolveMetadataTest.groovy
    • -2
    • +2
    ./VariantFilesMetadataRulesTest.groovy
  1. … 18 more files in changeset.
Remove derived enforced-platform variants

Instead, implement them with strict versions for external modules.

    • -7
    • +1
    ./DefaultMavenModuleResolveMetadataTest.groovy
    • -2
    • +2
    ./VariantFilesMetadataRulesTest.groovy
  1. … 18 more files in changeset.
Remove derived enforced-platform variants

Instead, implement them with strict versions for external modules.

    • -7
    • +1
    ./DefaultMavenModuleResolveMetadataTest.groovy
    • -2
    • +2
    ./VariantFilesMetadataRulesTest.groovy
  1. … 18 more files in changeset.
Revert "Revert "Merge branch 'release'""

This reverts commit 67b8bb8f18f854f45a2f5ec52cc9c8a25981e2f2.

This restores the merge attempt from earlier.

    • -1
    • +1
    ./AbstractDependencyMetadataRulesTest.groovy
    • -3
    • +3
    ./DefaultMavenModuleResolveMetadataTest.groovy
    • -1
    • +1
    ./DefaultMutableIvyModuleResolveMetadataTest.groovy
    • -7
    • +7
    ./DefaultMutableMavenModuleResolveMetadataTest.groovy
    • -1
    • +1
    ./VariantFilesMetadataRulesTest.groovy
  1. … 62 more files in changeset.
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
    • +1
    ./AbstractDependencyMetadataRulesTest.groovy
    • -3
    • +3
    ./DefaultMavenModuleResolveMetadataTest.groovy
    • -1
    • +1
    ./DefaultMutableIvyModuleResolveMetadataTest.groovy
    • -7
    • +7
    ./DefaultMutableMavenModuleResolveMetadataTest.groovy
    • -1
    • +1
    ./VariantFilesMetadataRulesTest.groovy
  1. … 62 more files in changeset.
Changes in Gradle Module Metadata loading

We no longer define any configurations, like default or the maven ones.

In the past, we still had these defined which allowed partial legacy

selection. But it made no sense since all these configurations would not

have any dependencies for example.

Fixes #10980

    • -1
    • +1
    ./AbstractDependencyMetadataRulesTest.groovy
    • -3
    • +3
    ./DefaultMavenModuleResolveMetadataTest.groovy
    • -1
    • +1
    ./DefaultMutableIvyModuleResolveMetadataTest.groovy
    • -7
    • +7
    ./DefaultMutableMavenModuleResolveMetadataTest.groovy
    • -1
    • +1
    ./VariantFilesMetadataRulesTest.groovy
  1. … 12 more files in changeset.
Changes in Gradle Module Metadata generation

We no longer define any configurations, like default or the maven ones.

In the past, we still had these defined which allowed partial legacy

selection. But it made no sense since all these configurations would not

have any dependencies for example.

    • -1
    • +1
    ./AbstractDependencyMetadataRulesTest.groovy
    • -3
    • +3
    ./DefaultMavenModuleResolveMetadataTest.groovy
    • -1
    • +1
    ./DefaultMutableIvyModuleResolveMetadataTest.groovy
    • -7
    • +7
    ./DefaultMutableMavenModuleResolveMetadataTest.groovy
    • -1
    • +1
    ./VariantFilesMetadataRulesTest.groovy
  1. … 12 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
    ./AbstractMutableModuleComponentResolveMetadataTest.groovy
  1. … 70 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.

    • -3
    • +3
    ./AbstractMutableModuleComponentResolveMetadataTest.groovy
  1. … 70 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.

    • -3
    • +3
    ./AbstractMutableModuleComponentResolveMetadataTest.groovy
  1. … 70 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.

    • -3
    • +3
    ./AbstractMutableModuleComponentResolveMetadataTest.groovy
  1. … 70 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).

    • -2
    • +2
    ./DefaultModuleComponentSelectorTest.groovy
  1. … 77 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).

    • -2
    • +2
    ./DefaultModuleComponentSelectorTest.groovy
  1. … 79 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).

    • -2
    • +2
    ./DefaultModuleComponentSelectorTest.groovy
  1. … 77 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).

    • -2
    • +2
    ./DefaultModuleComponentSelectorTest.groovy
  1. … 77 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).

    • -2
    • +2
    ./DefaultModuleComponentSelectorTest.groovy
  1. … 77 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).

    • -2
    • +2
    ./DefaultModuleComponentSelectorTest.groovy
  1. … 77 more files in changeset.
Make evaluation of base variant rules lazy

    • -0
    • +33
    ./VariantFilesMetadataRulesTest.groovy
  1. … 6 more files in changeset.