Gradle

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
signing plugin: use SHA512 instead of SHA1 when signing artifacts

PGP signs a digest, so MITM is still possible provided an attacker can update

the artifact in such a way that its SHA1 is intact.

Relevant article is https://medium.com/@jonathan.leitschuh/many-of-these-gpg-signatures-are-signed-with-sha-1-which-is-vulnerable-to-a-second-preimage-attack-67104d827930

Signed-off-by: Vladimir Sitnikov <sitnikov.vladimir@gmail.com>

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

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

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

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

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

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

  1. … 63 more files in changeset.
Adjust teamcity configuration

    • -3
    • +3
    /.teamcity/Gradle_Check/model/CIBuildModel.kt
Adjust teamcity configuration

    • -3
    • +3
    /.teamcity/Gradle_Check/model/CIBuildModel.kt
Remove unused code

Remove unused code

Add internal system property to disable task realization and serialization GradleProjectBuilder

Add internal system property to disable task realization and serialization in GradleProjectBuilder

Add system property to remove tasks from GradleProject model

Add system property to remove tasks from GradleProject model

Add system property to remove tasks from GradleProject model

Add system property to remove tasks from GradleProject model

Stop after 15 retries

Stop after 15 retries

Schedule failed builds in same run

Schedule failed builds in same run

Upgrade AGP nightly in instant execution tests

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

Upgrade AGP nightly in instant execution tests

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

Schedule builds for flakiness detection in inner loop

Schedule builds for flakiness detection in inner loop

Update auto apply scan plugin to 2.4.2

Update auto apply scan plugin to 2.4.2

Support variant and file derivation in realized metadata

This required a couple of changes:

- artifacts are now always explicitly serialized for each configuration

- variant derivation is implemented for variants and for configurations

in maven (derived variants) and ivy

- If a ivy module has configurations (variants) that have been added by

a rule, the realized version uses this information to opt-into

variant aware resolution

Add missing import

Document shortcomings of IncrementalTaskInputs