Gradle

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Change order of supertype visiting to restore old behavior

In the past when a supertype and an implemented interface conflicted wrt the type of a property, we picked the interface. This change restores that behavior, and thus fixes a bunch of tests.

However, this is not a proper fix for the problem. We should instead have the following behavior:

- if supertype and subtype disagree in the annotation used for a property, subtype should always win

- if supertypes (superclass and implemented interfaces) disagree, we should decide which annotation wins by observing an ordering between them, e.g. @Internal having lower priority than other type annotations

- if supertypes disagree, and they all have the same priority/ordering, it should be reported as a conflict the same way we report multiple annotations on the same property in the same class

Change order of supertype visiting to restore old behavior

In the past when a supertype and an implemented interface conflicted wrt the type of a property, we picked the interface. This change restores that behavior, and thus fixes a bunch of tests.

However, this is not a proper fix for the problem. We should instead have the following behavior:

- if supertype and subtype disagree in the annotation used for a property, subtype should always win

- if supertypes (superclass and implemented interfaces) disagree, we should decide which annotation wins by observing an ordering between them, e.g. @Internal having lower priority than other type annotations

- if supertypes disagree, and they all have the same priority/ordering, it should be reported as a conflict the same way we report multiple annotations on the same property in the same class

Change order of supertype visiting to restore old behavior

In the past when a supertype and an implemented interface conflicted wrt the type of a property, we picked the interface. This change restores that behavior, and thus fixes a bunch of tests.

However, this is not a proper fix for the problem. We should instead have the following behavior:

- if supertype and subtype disagree in the annotation used for a property, subtype should always win

- if supertypes (superclass and implemented interfaces) disagree, we should decide which annotation wins by observing an ordering between them, e.g. @Internal having lower priority than other type annotations

- if supertypes disagree, and they all have the same priority/ordering, it should be reported as a conflict the same way we report multiple annotations on the same property in the same class

Change order of supertype visiting to restore old behavior

In the past when a supertype and an implemented interface conflicted wrt the type of a property, we picked the interface. This change restores that behavior, and thus fixes a bunch of tests.

However, this is not a proper fix for the problem. We should instead have the following behavior:

- if supertype and subtype disagree in the annotation used for a property, subtype should always win

- if supertypes (superclass and implemented interfaces) disagree, we should decide which annotation wins by observing an ordering between them, e.g. @Internal having lower priority than other type annotations

- if supertypes disagree, and they all have the same priority/ordering, it should be reported as a conflict the same way we report multiple annotations on the same property in the same class

Change order of supertype visiting to restore old behavior

In the past when a supertype and an implemented interface conflicted wrt the type of a property, we picked the interface. This change restores that behavior, and thus fixes a bunch of tests.

However, this is not a proper fix for the problem. We should instead have the following behavior:

- if supertype and subtype disagree in the annotation used for a property, subtype should always win

- if supertypes (superclass and implemented interfaces) disagree, we should decide which annotation wins by observing an ordering between them, e.g. @Internal having lower priority than other type annotations

- if supertypes disagree, and they all have the same priority/ordering, it should be reported as a conflict the same way we report multiple annotations on the same property in the same class

Add test

Add test

Add test

Add test

Add test

Add test

Publication of resolved versions for Ivy xml

While the feature was added for the Gradle metadata linked to an Ivy

publication, it was missed for the Ivy xml itself.

This commit corrects that, relying on the usage context attributes to

map the Ivy dependency to the requested resolved configuration.

Fixes #8948

Fix assertions in Maven publishing test

The assertions were not complete enough and would have kept passing even

if the feature around publishing resolved version was broken for the

Maven metadata publication.

Fix several tests

  1. … 5 more files in changeset.
Fix several tests

  1. … 5 more files in changeset.
Fix several tests

  1. … 5 more files in changeset.
Fix several tests

  1. … 5 more files in changeset.
Fix several tests

  1. … 5 more files in changeset.
Fix several tests

  1. … 5 more files in changeset.
Polish `InstantExecution`

Add `compileGroovy` integration test

Polish `DefaultGradleLauncher`

Dedupe `gradle.getServices().get(...)`.

Don't break until setter is found

Polish `InstantExecution`

Remove redundant curly braces.

Add unit test for `fillTheGapsOf`

Add some diagnostics when a task property cannot be store or loaded for instant execution

Rename synthetic root project to `instant-execution`

Day 3 - Handle multi-level subproject tasks

Polish `Path`

Declare nullable parameter and return type.

Polish `InstantExecutionIntegrationTest`

Remove unnecessary system property value.