Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Some unit tests and fixes for determining whether to eagerly evaluate a `Provider` instance when serializing to the instant execution cache.

Also fixed an issue where `map { }` could not be called from the Groovy DSL on the result of `Provider.map { }`.

    • -0
    • +72
    ./gradle/api/internal/provider/PropertySpec.groovy
  1. … 12 more files in changeset.
Apply `Anonymous type can be replaced with lambda` inspection the whole project

  1. … 665 more files in changeset.
Apply `Explicit type can be replaced with <>` inspection the whole project

    • -1
    • +1
    ./gradle/api/internal/rules/DefaultRuleAwarePolymorphicNamedEntityInstantiator.java
  1. … 907 more files in changeset.
Some refactoring of the collection and map property implementations.

    • -6
    • +60
    ./gradle/api/internal/provider/PropertySpec.groovy
  1. … 4 more files in changeset.
Some refactoring of the collection and map property implementations.

    • -6
    • +60
    ./gradle/api/internal/provider/PropertySpec.groovy
  1. … 4 more files in changeset.
Change the behaviour of `Property.set(null)` so that the property's convention is used, if defined, instead of using 'not defined'.

    • -14
    • +62
    ./gradle/api/internal/provider/PropertySpec.groovy
  1. … 8 more files in changeset.
Change the behaviour of `Property.set(null)` so that the property's convention is used, if defined, instead of using 'not defined'.

    • -14
    • +62
    ./gradle/api/internal/provider/PropertySpec.groovy
  1. … 8 more files in changeset.
Consolidated some `FileSystemLocation` implementations and added some unit test coverage.

    • -0
    • +1066
    ./gradle/api/internal/provider/PropertySpec.groovy
    • -0
    • +299
    ./gradle/api/internal/provider/ProviderSpec.groovy
  1. … 11 more files in changeset.
Consolidated some `FileSystemLocation` implementations and added some unit test coverage.

    • -0
    • +1066
    ./gradle/api/internal/provider/PropertySpec.groovy
    • -0
    • +299
    ./gradle/api/internal/provider/ProviderSpec.groovy
  1. … 11 more files in changeset.
Use method reference, where applicable

  1. … 169 more files in changeset.
Use method reference, where applicable

  1. … 167 more files in changeset.
Organize imports

  1. … 338 more files in changeset.
Replace anonymous classes with lambdas

  1. … 710 more files in changeset.
Replace anonymous classes with lambdas

  1. … 694 more files in changeset.
Invert the relationship between 'modelCore' and 'coreApi' projects, so that 'modelCore' can contain types that reference the public core API.

    • -26
    • +0
    ./gradle/model/ModelTypeTesting.groovy
  1. … 55 more files in changeset.
Replace usages of org.gradle.api.Nullable

With javax.annotation.Nullable.

  1. … 460 more files in changeset.
Improve fully qualified representation of nested model types

Use `.` instead of `$` to separate the enclosing type name from the

nested type name.

    • -0
    • +26
    ./gradle/model/ModelTypeTesting.groovy
  1. … 24 more files in changeset.
Initialize native services for ProjectRegistrySpec

Cleanup static directory

Remove deprecated methods on TestUtil (#672)

In order to use project builder correctly without having

leaking files on windows it is necessary to initialize

the test fixture for NativeServices and clean up

the test directory after building.

AbstractProjectBuilderSpec provides a nice base class

for Groovy tests.

I removed the deprecated methods since using them leads

to files lying around. Migrating all the usages to the "new"

way ensures it is used correctly.

  1. … 97 more files in changeset.
Simplify setting target for new reference node

+review REVIEW-5821

  1. … 6 more files in changeset.
Contextualize debug messages with project path

  1. … 6 more files in changeset.
Revert "Promote o.g.model/{internal/core/rule/describe=>}/ModelRuleDescriptor"

This reverts commit de9e06338062d7ff2933717e1c30fbf0fb6c50d2 following a

review in which we determined that letting the indirect cycle persist is

a lesser evil that promoting ModelRuleDescriptor to public status.

Note again that the original commit, nor this reversion of it has any

impact on Classycle errors, as it appears to be incapable of detecting

this kind of (very common) cycle.

    • -1
    • +1
    ./gradle/api/internal/rules/DefaultRuleAwarePolymorphicNamedEntityInstantiator.java
  1. … 82 more files in changeset.
Expose struct bindings store to node initializer registry

+review REVIEW-5761

  1. … 4 more files in changeset.
Coalesce o.g.m.{collection.internal=>internal.core}

This change removes a "feedback dependency" at the package level, which

is an indirect form of a package cycle.

In this case, collection.internal.ModelMapModelProjection depended on

internal.manage.instance.ManagedInstance while at the same time types in

internal.manage.extract depended on

collection.internal.ChildNodeInitializerStrategy* types.

So while there was no direct cycle between any two packages, there was

a an indirect cycle or between different subpackages of

collection.internal and collection.manage.

Indirect cycles are just as indicative of a design problem as their

direct counterparts, but unfortunately it appears that Classycle is not

capable of detecting them. Fortunately, other tools are. This screenshot

taken from Structure101 Studio visualizes the indirect cycle described

above: https://imgur.com/00FyduF.

It appears that the presence of these types in collection.internal was

probably an oversight to begin with. This package did start out with

proper collection types such as DefaultManagedSet and

DefaultCollectionBuilder, but these were removed quite some time ago in

commit 699abb21985e8126742007cb2e0daeae34316756. As such, this commit

resolves the indirect cycle simply by moving the offending types from

collection.internal into internal.core, where they look to be a better

fit anyway.

  1. … 13 more files in changeset.
Promote o.g.model/{internal/core/rule/describe=>}/ModelRuleDescriptor

Much like the previous commit, this change resolves an indirect package

cycle. Unlike the previous commit, however, it does so by promoting a

previously intenal type (ModelRuleDescriptor) to public API status.

There are several exception types resident in org.gradle.model that

depend on ModelRuleDescriptor and expose that dependency through their

constructors. This alone provides a rationale for promoting

ModelRuleDescriptor to public status, and resolving the cycle is now an

additional motivation.

Note that while the package structure within on the internal side was

org.gradle.model.internal.core.rule.describe, ModelRuleDescriptor has

been promoted here directly to org.gradle.model, i.e. the

core.rule.describe subpackaging has not been mirrored into the public

package structure. The reason for doing this is to avoid introducing a

dependency from a higher level package (org.gradle.model) to a

subpackage. In general, package dependencies should always flow upward

from subpackages to parent packages in a given hierarchy, and not the

other way around. There are many counterexamples of this throughout the

codebase today, but that is no reason to perpetuate the practice.

    • -1
    • +1
    ./gradle/api/internal/rules/DefaultRuleAwarePolymorphicNamedEntityInstantiator.java
  1. … 80 more files in changeset.
Merged `ModelPromise.canBeViewedAsMutable()` and `canBeViewedAsImmutable()` as the set of types is always the same.

This avoids doing a compatibility check twice on non match (once for immutable and once for mutable). This check is a hotspot at configuration time.

  1. … 22 more files in changeset.
Added a rough implementation of `MutableModeNode.applyToSelf()` for reference model nodes.

  1. … 8 more files in changeset.
`ModelAction` no longer needs to be parameterized.

  1. … 34 more files in changeset.
Treat `@RuleInput` properties on `RuleSource` types as references to implicit inputs for all rules on the rule source.

Moved responsibility for applying a rule to a particular scope up from `ModelRegistry` to `ModelRuleExtractor`. Now, all `RuleAction` instances applied to a `ModelRegistry` are applied relative to the root element, and it is the caller's responsibility to scope the action as required before registering it.

+review REVIEW-5756

  1. … 16 more files in changeset.