Clone Tools
  • last updated a few seconds ago
Constraints: committers
Constraints: files
Constraints: dates
Fix UnicastMessagingIntegrationTest failing after being more strict in setting up object connection

Update wrapper to latest nightly

Prepering for 3.3 release branching.

    • -2
    • +2
Add limitation to composite builds documentation

+review REVIEW-6405

Improve error message in case we fallback to the `default` configuration but it's not consumable

Since we call fallback on the `default` configuration in case no matching configuration is found with the

consumer attributes, it is possible that this configuration is not consumable, in which case dependency

resolution should fail. This was the case but the error message was unclear, as it was somehow telling

the user that they had selected `default` explicitly. Instead, the error message now lists the configurations

which failed to match, with their respective attributes.

Fix classloading issues when having multiple message types in ObjectConnection

Revalidate that selected configurations match the requested attributes

This commit changes the behavior of dependency resolution in case a selected configuration doesn't match

the requested attributes. It could happen in two cases:

- in case no matching configuration is found, we fallback to the `default` configuration, which could have attributes

that did *not* match (it was part of the selection, but in the end since no configuration was matching, it was selected


- in case an explicit configuration was chosen. In that case, we didn't check that the selected configuration matched

the consumer attributes.

Error messages have been improved as part of this story. It's worth noting that this commit does NOT change the

selection algorithm, and we will always fallback to the `default` configuration in case no match is found. The only

thing it does is really revalidating that this fallback is compatible.

See gradle/performance#233

Look for a transformation first before filtering

In transformation matching we want to determine if a transformation can

make an artifact a better match as before. But since we ignore all

attributes that are not set in attribute filtering, we have to be

careful. An artifact may already match before transformation (but

matching can also mean that the artifact is filtered out). Hence,

we have to check if there is a transformation first.

Dynamically decide which attributes are used for artifact matching

Only the attributes that are set on the artifact need to be considered

for attribute matching. This needs to be dynamic because otherwise we

could not use any additional attribute except for the pre-defined

artifact attributes.

Fix test by overloading 'artifactType'

Ideally, we would specify a custom attribute for the filter,

but custom attributes are not considered when matching artifacts,

or when finding an `ArtifactTransform` instance.

Test that `ArtifactTransform` can be used to filter artifacts

This test demonstrates how this would work if custom attributes

were considered in artifact transformation. Unfortunately this

doesn't yet work.

Further changes to push the variants of a configuration through to artifact selection. Changed the result of artifact resolution from a set of artifacts to a set of variants. Currently only the first variant is selected to provide the artifacts for a configuration.

  1. … 4 more files in changeset.
Some tweak to type signatures on `ConfigurationMetadata` to allow local and external types to specialise the artifacts and dependencies they expose.

Some changes to wiring to attach the outgoing variants for each configuration to the component metadata used during resolution. The variants are ignored for now.

Split JVM/OS memory events and add coverage

Start MemoryStatusBroadcaster for in-process tests

See dd06f47529650d15952e429c88ba3e461d2612cc

Add hacky reproducible example for #933

TeamCity change in 'Gradle :: Branches :: Checkpoints' project: triggers of 'Stage 2 - Linux Basic Coverage' build configuration were updated

TeamCity change in 'Gradle :: Branches :: Checkpoints' project: triggers of 'Stage 2 - Linux Basic Coverage' build configuration were updated

Investigate some test tasks

    • -0
    • +2
TeamCity change in 'Gradle :: Branches :: Checkpoints' project: triggers of 'Stage 5 - Full' build configuration were updated

TeamCity change in 'Gradle :: Branches :: Checkpoints' project: triggers of 'Stage 2 - Linux Basic Coverage' build configuration were updated

Fix smoke test after wrapper upgrade

    • -1
    • +0
Upgrade to latest nightly

    • -2
    • +2
    • -2
    • +2
Re-enable test with `using m2`

Revert verifying inputs again

We still have some problems which we need to investigate

+review REVIEW-6402

Add :ui:integTest to tasks to investigate

    • -0
    • +1
Add backwards compatibility check

Check that we don't break custom tasks that use the inputs.dir, inputs.files or inputs.file

These depend on leaked internal types

+review REVIEW-6403

Simplify the decorator tests

+review REVIEW-6404

Clean-up test

+review REVIEW-6404

Add TODO about error handling in HttpBuildCache

+review REVIEW-6404