ResolveTestFixture.groovy

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Some initial test coverage

  1. … 2 more files in changeset.
Some initial test coverage

  1. … 2 more files in changeset.
Some initial test coverage

  1. … 2 more files in changeset.
Add strict reasons check to resolve fixtures

Add strict reasons check to resolve fixtures

Add strict reasons check to resolve fixtures

Add strict reasons check to resolve fixtures

Add strict reasons check to resolve fixtures

Add strict reasons check to resolve fixtures

Add BY_ANCESTORS selection reason

  1. … 2 more files in changeset.
Add BY_ANCESTORS selection reason

  1. … 2 more files in changeset.
Add BY_ANCESTORS selection reason

  1. … 2 more files in changeset.
Add support for 'forSubgraph' to metadata test fixtures

  1. … 7 more files in changeset.
Add support for 'forSubgraph' to metadata test fixtures

  1. … 7 more files in changeset.
Add support for 'forSubgraph' to metadata test fixtures

  1. … 7 more files in changeset.
Add support for 'forSubgraph' to metadata test fixtures

  1. … 7 more files in changeset.
Add support for 'forSubgraph' to metadata test fixtures

  1. … 7 more files in changeset.
Add support for Java test fixtures

This commit introduces conventional support for _test fixtures_

in the Java ecosystem.

The `java` extension, available when applying either the `java`

or `java-library` plugins, now adds a couple of methods:

- `enableTestFixtures`, which will create an additional source

set for test fixtures

- `usesTestFixturesOf`, which declares that this project makes

use of the test fixtures of another project or external module

This feature builds on top of the existing feature variant

infrastructure, which means that:

- test fixtures are published (as optional dependencies in Maven,

as variants with Gradle metadata)

- test fixtures have a conventional capability

The capability for test fixtures is `test-fixtures`, so it means

that if the project has a name `foo`, then its test fixtures

would be published with a capability name of `foo-test-fixtures`.

Test fixtures expose an API and an implementation, available

through the `testFixturesApi` and `testFixturesImplementation`

configurations.

When test fixtures are enabled, the test fixtures API automatically

gets a dependency onto the main component (aka `src/main/java`).

  1. … 9 more files in changeset.
Add support for Java test fixtures

This commit introduces conventional support for _test fixtures_

in the Java ecosystem.

The `java` extension, available when applying either the `java`

or `java-library` plugins, now adds a couple of methods:

- `enableTestFixtures`, which will create an additional source

set for test fixtures

- `usesTestFixturesOf`, which declares that this project makes

use of the test fixtures of another project or external module

This feature builds on top of the existing feature variant

infrastructure, which means that:

- test fixtures are published (as optional dependencies in Maven,

as variants with Gradle metadata)

- test fixtures have a conventional capability

The capability for test fixtures is `test-fixtures`, so it means

that if the project has a name `foo`, then its test fixtures

would be published with a capability name of `foo-test-fixtures`.

Test fixtures expose an API and an implementation, available

through the `testFixturesApi` and `testFixturesImplementation`

configurations.

When test fixtures are enabled, the test fixtures API automatically

gets a dependency onto the main component (aka `src/main/java`).

  1. … 9 more files in changeset.
Add support for Java test fixtures

This commit introduces conventional support for _test fixtures_

in the Java ecosystem.

The `java` extension, available when applying either the `java`

or `java-library` plugins, now adds a couple of methods:

- `enableTestFixtures`, which will create an additional source

set for test fixtures

- `usesTestFixturesOf`, which declares that this project makes

use of the test fixtures of another project or external module

This feature builds on top of the existing feature variant

infrastructure, which means that:

- test fixtures are published (as optional dependencies in Maven,

as variants with Gradle metadata)

- test fixtures have a conventional capability

The capability for test fixtures is `test-fixtures`, so it means

that if the project has a name `foo`, then its test fixtures

would be published with a capability name of `foo-test-fixtures`.

Test fixtures expose an API and an implementation, available

through the `testFixturesApi` and `testFixturesImplementation`

configurations.

When test fixtures are enabled, the test fixtures API automatically

gets a dependency onto the main component (aka `src/main/java`).

  1. … 9 more files in changeset.
Add support for Java test fixtures

This commit introduces conventional support for _test fixtures_

in the Java ecosystem.

The `java` extension, available when applying either the `java`

or `java-library` plugins, now adds a couple of methods:

- `enableTestFixtures`, which will create an additional source

set for test fixtures

- `usesTestFixturesOf`, which declares that this project makes

use of the test fixtures of another project or external module

This feature builds on top of the existing feature variant

infrastructure, which means that:

- test fixtures are published (as optional dependencies in Maven,

as variants with Gradle metadata)

- test fixtures have a conventional capability

The capability for test fixtures is `test-fixtures`, so it means

that if the project has a name `foo`, then its test fixtures

would be published with a capability name of `foo-test-fixtures`.

Test fixtures expose an API and an implementation, available

through the `testFixturesApi` and `testFixturesImplementation`

configurations.

When test fixtures are enabled, the test fixtures API automatically

gets a dependency onto the main component (aka `src/main/java`).

  1. … 9 more files in changeset.
Change ResolveTestFixture to default to 'runtimeClasspath'

  1. … 1 more file in changeset.
Change ResolveTestFixture to default to 'runtimeClasspath'

  1. … 1 more file in changeset.
Change ResolveTestFixture to default to 'runtimeClasspath'

  1. … 1 more file in changeset.
Adjust test to changes in ResolveTestFixture

  1. … 1 more file in changeset.
Use java-library and its configurations in ResolveTestFixture

This mainly influences the composite build tests which intensively

use this fixture.

  1. … 13 more files in changeset.
Fix Groovy/Java library compatibility

This commit fixes the Groovy + Java Library compatibility,

by making sure that if, and only if, the Java Library is

applied on a project that also applies the Java Library

plugin, then the correct variants is selected.

  1. … 4 more files in changeset.
Introduce a `JAVA_API_JARS` usage

This commit introduces a new `JAVA_API_JARS` usage, mirror

to the `JAVA_RUNTIME_JARS` usage. This is both for consistency,

and to make sure that the `JAVA_API` and `JAVA_RUNTIME` usages

are limited to cases where the consumer doesn't care, or when

a producer doesn't have a more specific usage to provide.

This is, for example, the case for Java platforms. It's worth

noting than in case a producer mixes both "generic" usages

and "specific" usages, selection is likely to produce unexpected

results, because of disambiguation rules.

The Java disambiguation rule has been simplified and now

supports more cases.

  1. … 37 more files in changeset.
Test for selecting multiple variants of a local project

This commit adds a test showing we can use variant-aware dependency management

to select 2 variants of the same project.

This test is not intended to be an example how to expose test fixtures,

it's only there for coverage.

  1. … 4 more files in changeset.
Support depending on multiple variants of the same component

This commit changes the resolution engine so that it is possible

to resolve multiple variants of the same component when using

variant-aware dependency management.

Before, in order to have 2 dependencies on the same component

but using different variants, one had to use explicit configuration

dependencies. Now, with this change, it is possible to have

two dependencies on the same component, but with different attributes.

Those components would resolve to different variants.

Special treatment is applied when attributes are declared on constraints:

in this case, we _merge_ the constraint attributes, and make sure that

the edge is computed using the merged attributes. Should they be

incompatible, the build would fail as before.

  1. … 29 more files in changeset.