DefaultConfigurationContainerSpec.groovy

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Use the `DomainObjectCollectionFactory` everywhere

    • -4
    • +4
    ./DefaultConfigurationContainerSpec.groovy
  1. … 39 more files in changeset.
Use the `DomainObjectCollectionFactory` everywhere

    • -4
    • +4
    ./DefaultConfigurationContainerSpec.groovy
  1. … 39 more files in changeset.
Revert "Revert "Merge branch 'sg/lazy/publish-register-2' into release""

This reverts commit 0937d57caa43dabc31d331dea6c9c0cf72de8607.

    • -1
    • +5
    ./DefaultConfigurationContainerSpec.groovy
  1. … 23 more files in changeset.
Allow the services required by a given class to be queried prior to creating any instances of that class. Use this to allow `ArtifactTransformDependencies` to be injected into artifact transforms using any of the service injection patterns (that is, via a constructor or a getter).

    • -1
    • +1
    ./DefaultConfigurationContainerSpec.groovy
  1. … 127 more files in changeset.
Revert "Merge branch 'sg/lazy/publish-register-2' into release"

This reverts commit 975120ec3997139e2e81e9ad4c03df89fa0748e5, reversing

changes made to 2eb24bc6b76a7d76b97036ca2c716730bc156d76.

    • -5
    • +1
    ./DefaultConfigurationContainerSpec.groovy
  1. … 24 more files in changeset.
Fix unit tests

    • -1
    • +5
    ./DefaultConfigurationContainerSpec.groovy
  1. … 1 more file in changeset.
Replace most direct usages of `DirectInstantiator` with indirect usages via `InstantiatorFactory` or test fixtures instead. This means more consistent behaviour in unit tests because the objects under test will behave more similarly to how they do at runtime. This also allows the decision of how the instantiation should behave to live in as few places as possible, so this can be more easily evolved and contextualized.

    • -3
    • +3
    ./DefaultConfigurationContainerSpec.groovy
  1. … 60 more files in changeset.
Emit build operations around container callback executions (core and dependencyMgmt containers) (#7734)

* Decorate taskcontainer callbacks to track application id

* Decorate plugin container callbacks

* Decorate repositoryContainer callbacks

* Decoreate configurations and configuration.dependencies container callbacks

* Decorate artifactTypesDecorator callbacks

* Dont emit build ops for internal declared callbacks

* Provide usercode context in beforeResolve / afterResolve callbacks

* keep compatibility for nebula.dependency-recommender plugin

* Put domain collection callback build ops behind feature toggle

* Decorate Provider.configure() methods

* Simplify container callback filtering and decoration

Previously, we had three classes collaborating to achieve this but now this is inlined into effectively one. While this creates a more complex implementation, that is still rather simple, it avoids the more problematic complexity of a complicated relationship between the three implementations that also required extra state and details to be propagated through all of the collections.

    • -1
    • +7
    ./DefaultConfigurationContainerSpec.groovy
  1. … 70 more files in changeset.
Add further information to unsafe configuration resolution warning

    • -1
    • +3
    ./DefaultConfigurationContainerSpec.groovy
  1. … 7 more files in changeset.
Add further information to unsafe configuration resolution warning

    • -1
    • +3
    ./DefaultConfigurationContainerSpec.groovy
  1. … 6 more files in changeset.
Split off value snapshotting and attributes related methods of TestUtil

    • -2
    • +2
    ./DefaultConfigurationContainerSpec.groovy
  1. … 64 more files in changeset.
Ensure root component metadata artifacts are resolved while project is mutable

This avoids concurrency issues where another project is resolving the configuration

while the project itself is also resolving it.

    • -1
    • +3
    ./DefaultConfigurationContainerSpec.groovy
  1. … 6 more files in changeset.
Fix failing unit tests

    • -1
    • +1
    ./DefaultConfigurationContainerSpec.groovy
  1. … 13 more files in changeset.
Fix failing unit tests

    • -1
    • +1
    ./DefaultConfigurationContainerSpec.groovy
  1. … 13 more files in changeset.
Add initial support component metadata supplier caching

This commit adds the infrastructure for caching of component metadata rules.

For now, the only kind of rule we can cache are the component metadata supplier

rules, which are used during dynamic version selection, but the executor

infrastructure can be reused to cache more kinds of rules.

The implementation relies on the principal that a "rule" can be safely cached if:

- the rule has no side effect, and uses the "class-based pattern"

- the implementation of the rule didn't change

- the inputs of the rule didn't change

For this, we introduce a new persistent cache (hence cross-build) with an in-memory

facing cache, that allows us to avoid the execution of a rule if the result is

already in the cache. The implementation makes use of _snapshotting_ to capture the

state of the inputs of a rule, which consists of the implementation of the rule and

its potential parameters. It's worth noting that at this stage we do not consider

the services the rule can use, it's going to be done in a subsequent commit.

This worked required a clarification of what an rule cares about (the result) in

opposition to what the user is faced with. For example, a component metadata supplier

rule output is a `ComponentMetadata`, but what we offer to the user, to build that

metadata, is a `ComponentMetadataSupplierDetails` instance. Similarly, component

metadata rules would have different kind of output and what the user manipulates.

The cache works with a primary key (for the first implemented cache, the key is the

module version identifier) and will invalidate the results based on the cache policy

(should refresh modules).

The persistent cache uses the snapshot as the key in the store. In theory, should we

consider that we have a nearly perfect hash function, we could instead use the hash

of the snapshot as the key. Measurements would have to be made to check if it's worth

implementing.

    • -1
    • +1
    ./DefaultConfigurationContainerSpec.groovy
  1. … 46 more files in changeset.
Add initial support component metadata supplier caching

This commit adds the infrastructure for caching of component metadata rules.

For now, the only kind of rule we can cache are the component metadata supplier

rules, which are used during dynamic version selection, but the executor

infrastructure can be reused to cache more kinds of rules.

The implementation relies on the principal that a "rule" can be safely cached if:

- the rule has no side effect, and uses the "class-based pattern"

- the implementation of the rule didn't change

- the inputs of the rule didn't change

For this, we introduce a new persistent cache (hence cross-build) with an in-memory

facing cache, that allows us to avoid the execution of a rule if the result is

already in the cache. The implementation makes use of _snapshotting_ to capture the

state of the inputs of a rule, which consists of the implementation of the rule and

its potential parameters. It's worth noting that at this stage we do not consider

the services the rule can use, it's going to be done in a subsequent commit.

This worked required a clarification of what an rule cares about (the result) in

opposition to what the user is faced with. For example, a component metadata supplier

rule output is a `ComponentMetadata`, but what we offer to the user, to build that

metadata, is a `ComponentMetadataSupplierDetails` instance. Similarly, component

metadata rules would have different kind of output and what the user manipulates.

The cache works with a primary key (for the first implemented cache, the key is the

module version identifier) and will invalidate the results based on the cache policy

(should refresh modules).

The persistent cache uses the snapshot as the key in the store. In theory, should we

consider that we have a nearly perfect hash function, we could instead use the hash

of the snapshot as the key. Measurements would have to be made to check if it's worth

implementing.

    • -1
    • +1
    ./DefaultConfigurationContainerSpec.groovy
  1. … 46 more files in changeset.
Lock validation and persist through graph visitor

This introduces validation of graph resolution with the lock file.

Added or missing dependencies in the graph compared to the lock

file cause a failure.

The visitor doing the validation is also used for trigerring

the persistence of the result.

Fixes #4862

    • -1
    • +3
    ./DefaultConfigurationContainerSpec.groovy
  1. … 28 more files in changeset.
Rename metadata builders

- `ConfigurationComponentMetaDataBuilder` -> `LocalComponentMetadataBuilder`

- `DependenciesToModuleDescriptorConverter` -> `LocalConfigurationMetadataBuilder`

    • -2
    • +2
    ./DefaultConfigurationContainerSpec.groovy
  1. … 21 more files in changeset.
Prefer source dependency rules in the root project over rules in nested projects

    • -2
    • +2
    ./DefaultConfigurationContainerSpec.groovy
  1. … 16 more files in changeset.
Reduce the path gymnastics in identifying configurations.

+review REVIEW-6571

    • -12
    • +2
    ./DefaultConfigurationContainerSpec.groovy
  1. … 12 more files in changeset.
Reduce the path gymnastics in identifying configurations.

+review REVIEW-6571

    • -12
    • +2
    ./DefaultConfigurationContainerSpec.groovy
  1. … 12 more files in changeset.
address further review feedback; make configuration project path lazy

    • -2
    • +14
    ./DefaultConfigurationContainerSpec.groovy
  1. … 4 more files in changeset.
Address review feedback on exposing script configuration details

    • -0
    • +1
    ./DefaultConfigurationContainerSpec.groovy
  1. … 6 more files in changeset.
Address review feedback on exposing script configuration details

    • -0
    • +1
    ./DefaultConfigurationContainerSpec.groovy
  1. … 6 more files in changeset.
Add service to provide ModuleVersionSelector for ComponentSelector

Instead of having the target `ModuleVersionSelector` travel with the dependency metadata,

we rely on `ComponentSelector` for a dependency, and only lookup the related module or

`ModuleVersionSelector` when actually required.

The logic to determine a `ModuleVersionSelector` from `ComponentSelector` is:

- For ModuleComponentSelector, convert directly

- For ProjectComponentSelector, lookup coordinates of target project

The new service is used to replace the following uses of `DependencyMetadata.requested`:

- To produce the details object provided to `eachDependency` (exposes ModuleVersionSelector)

- To produce `UnresolvedDependency` instances for `ResolvedConfiguration`

    • -1
    • +4
    ./DefaultConfigurationContainerSpec.groovy
  1. … 26 more files in changeset.
Retain the value of a variant attribute as an isolated value, rather than retaining the original value. Attribute values are snapshot at the point where the attribute is registered and are isolated from further changes to the original value.

This change allows attribute matching to more safely happen in parallel and means that attribute values can behave more consistently with other features that use isolated and snapshot values, such as task inputs or artifact transforms.

    • -3
    • +3
    ./DefaultConfigurationContainerSpec.groovy
  1. … 18 more files in changeset.
Add VCS mapping API

Incorporate upstream changes

    • -1
    • +4
    ./DefaultConfigurationContainerSpec.groovy
  1. … 38 more files in changeset.
Unify BuildOperationExecutor and BuildOperationProcessor APIs

This introduces the following `BuildOperationExecutor`

interface (as outlined in gradle/gradle#1676):

void run(RunnableBuildOperation buildOperation);

<T> T call(CallableBuildOperation<T> buildOperation);

<O extends RunnableBuildOperation> void runAll(

Action<BuildOperationQueue<O>> schedulingAction);

<O extends BuildOperation> void runAll(

BuildOperationWorker<O> worker,

Action<BuildOperationQueue<O>> schedulingAction);

To accomplish this, the following changes were performed:

- Various representation of build operations have been merged into

1) BuildOperation (with sub-interfaces)

-> declare and describe a build operation

2) BuildOperationDescriptor (BuildOperationDescriptor.Builder)

-> describe a build operation

3) BuildOperationState

-> represents a running build operation, with run state, start time,

parent relationship information, and description

- The DefaultBuildOperationExecutor and DefaultBuildOperationProcessor

implementations have been merged in DefaultBuildOperationExecutor,

which is now build session scoped.

    • -1
    • +1
    ./DefaultConfigurationContainerSpec.groovy
  1. … 180 more files in changeset.
Pass the module identifier factory down to module forcing resolve rule

    • -1
    • +8
    ./DefaultConfigurationContainerSpec.groovy
  1. … 11 more files in changeset.
Rework caching of `ImmutableAttributes`

This commit completly reworks the storage of attributes and immutable attributes. At the root of

the change is the `ImmutableAttributesFactory`, which is used to create, combine and cache

immutable attribute sets. This factory lives at the build scope level, and does *not* use a `Map`

to represent attributes. Instead, it creates a "tree" of attributes, which are mutated by adding

a new attribute. This dramatically reduces the memory pressure caused by the creation of immutable

attributes, as long at the set of attributes and values is small (which should be the case).

It's worth noting that the factory is not a _perfect_ cache. For example, depending on the order

of attributes, several "sets", corresponding to several "path to root" can be created. For example,

we can see `(foo, bar, baz)` and `(baz, foo, bar)`. Even if they are equivalent, there will be

2 distinct paths in the cache. This is not a problem, since equality check works, and the overhead

of de-duplicating is significant, so doesn't bring any advantage.

The commit also introduces a `lockAttributes` method on `ConfigurationInternal`, which allows

effectively locking the attribute set of a configuration, transforming it to an immutable

attribute set. This avoids, if multiple consumers ask for the configuration attributes in an

immutable form, to do the conversion several times (thus reducing the pressure again).

Last but not least, `DefaultAttributesContainer` is the mutable version of the attribute

container, and relies internally on `ImmutableAttributes`. This allows us to keep the semantics

of mutable attributes during the configuration phase (and, in particular, changes the attributes

of a configuration after the artifacts are created should be visible to the artifact attributes),

while deduplicating attributes and keeping memory usage low at the same time.

The drawback of this approach is the general complexity of the code, and having to pass the

`ImmutableAttributesFactory` along.

    • -1
    • +3
    ./DefaultConfigurationContainerSpec.groovy
  1. … 39 more files in changeset.