Clone Tools
  • last updated a few seconds ago
Constraints: committers
Constraints: files
Constraints: dates
Address review items

- don't register core classloader when registering incoming messages

- remove unused overload of ObjectConnectionBuilder#addIncoming

- cleanup WorkerDaemonServiceIntegrationTest

Align terminology with Jacoco configuration options

Makes it easier for users to map configuration options to Jacoco documentation. Aligns the configuration options with Maven plugin and Ant tasks.

Changed artifact selection to select zero or one variant of each node in the dependency graph to be included in the result, whether directly or as an input to a transformation.

Artifacts from the selected variant are still filtered by artifact type, which leads to some confusing behaviour. The filtering will be replaced by an error in a later change.

  1. … 14 more files in changeset.
Fixed `AttributeContainer.getAttributes()` on empty attribute container.

Use String data type instead of enum

Allows for better forward and backward capability in case JaCoCo decides to introduce new values or change existing ones.

Changing system memory warning to print at info

This is to prevent the additional output from messing up tests that

check output.

Bump up version number

Better IDE support for Closure parameters

Enhance samples and documentation

Fixing some flakiness in memory status integration test

Flag test that fails offline

Include link to the user guide in builtin plugin extensions

See #168

Keep builtin plugin extensions at the PluginDependenciesSpec level

See #168

Look for transformed artifact in cache first

With this change, we only lookup the `ArtifactTransform` and

checking if attributes match multiple once for a particular artifact/file.

Minor cleanup of memory broadcaster

remove debugging output

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