NameValidatorTest.groovy

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Merge branch 'release'

  1. … 15 more files in changeset.
Merge remote-tracking branch 'origin/master-test' into release-test

  1. … 15 more files in changeset.
Do not run the constructors of tasks that are deserialized from the instant execution cache.

  1. … 22 more files in changeset.
Do not run the constructors of tasks that are deserialized from the instant execution cache.

  1. … 22 more files in changeset.
Do not run the constructors of tasks that are deserialized from the instant execution cache.

  1. … 22 more files in changeset.
Do not run the constructors of tasks that are deserialized from the instant execution cache.

  1. … 21 more files in changeset.
Use the `DomainObjectCollectionFactory` everywhere

  1. … 39 more files in changeset.
Use the `DomainObjectCollectionFactory` everywhere

  1. … 39 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. … 127 more files in changeset.
Revert "Merge branch 'sg/lazy/publish-register-2' into release"

This reverts commit 975120ec3997139e2e81e9ad4c03df89fa0748e5, reversing

changes made to 2eb24bc6b76a7d76b97036ca2c716730bc156d76.

  1. … 24 more files in changeset.
Fix test constructor signature

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.

  1. … 60 more files in changeset.
Remove pointless decoration from `TaskFactory` as the instantiation takes care of this.

  1. … 7 more files in changeset.
Decorate all domain collection container for emitting build ops (#7876)

* Update all domain object container with decorator for tracing executed callback actions

* Add decorator to a ll required occurances of DefaultDomainObjectSet

* Keep ctor for DefaultPolymorphicDomainObjectContainer as its used in gradle-idea-ext plugin

* Bring back DefaultDomainObjectSet constructor used by the android plugin

* keep backwards compatibility

  1. … 122 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. … 70 more files in changeset.
Add further information to unsafe configuration resolution warning

  1. … 7 more files in changeset.
Add further information to unsafe configuration resolution warning

  1. … 6 more files in changeset.
Split off value snapshotting and attributes related methods of TestUtil

  1. … 64 more files in changeset.
Remove support for invalid domain object names

Prior to this commit, the use of invalid characters in names of projects

and container objects was deprecated. Now, it fails the build by

throwing an `InvalidUserDataException`.

Since spaces in directory names are supported on all supported platforms

and users have complained about them being deprecated, they are no

longer considered invalid.

Resolves #6288.

  1. … 6 more files in changeset.
Separate `ITaskFactory` from `NamedEntityInstantiator<Task>` so that the instantiator is applied as a decoration over the factory.

  1. … 37 more files in changeset.
Raise version to 5.0

  1. … 24 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. … 6 more files in changeset.
Expose deprecation warning messages and stacktraces via build operations (#5881)

Expose deprecation warnings as operation progress events

- introduce split of message, warning and advice

- make deprecation progress events immutable

- rework deprecation handling/messages to support more a richer model

- update build operation progress model

- tweak existing deprecation warnings to match new model

- Add performance test + make stacktrace calculation for build ops lazy

- Always include a trace with FeatureUsage now that its always required

  1. … 65 more files in changeset.
Emit build operations for task registration / realization (#5610)

* Wire in op executor to task container

* Add internal task id

* Add binary compatibility exception

* Add as-light-as-possible build ops for eagerly created tasks

* Use op task ids when creating tasks

* Emit light build ops for lazily realized tasks

* Only fire task creation build ops when collecting task stats

* Provide rich details for task creation build ops

* Use groovy method rather than JDK8 method

* Wire in op executor to task container

* Add internal task id

* Add binary compatibility exception

* Add as-light-as-possible build ops for eagerly created tasks

* Use op task ids when creating tasks

* Emit light build ops for lazily realized tasks

* Only fire task creation build ops when collecting task stats

* Provide rich details for task creation build ops

* Use groovy method rather than JDK8 method

* Change test to use new register method

* Make NullBuildOperationExecutor a singleton

* Add note about opt-in to operations being empty

* Consolidate name/type/uniqueId into TaskIdentity

Reduces the number of args flying around, consolidates how identity paths etc. are calculated and enforces only one instance of such paths.

* Don't nest realize op for eagerly created lazy task

* Add test for nesting of task realize build ops

  1. … 25 more files in changeset.
Fix failing unit tests

  1. … 13 more files in changeset.
Fix failing unit tests

  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. … 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. … 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. … 28 more files in changeset.
Refactor SingleMessageLogger

Signed-off-by: Bo Zhang <bo@gradle.com>

  1. … 20 more files in changeset.