Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Introduce creation of parameterized tooling models

This commit introduces the possibility of passing parameters through the

Tooling API to the model builders in order to create models based on

information received by the client.

This feature allows plugins to register a model builder for a given

model and parameter and then build models based on the received

parameter. It is preferable to passing gradle properties for two

reasons: first convenience and second because parameters can be created

inside the BuildAction.

A new interface ToolingParameterizedModelBuilder was created and should

be extended by parameterized builders. New methods were added to the

BuildController in order to build models with parameters. In order to

keep cross version compatibility, new protocol interfaces were created.

  1. … 35 more files in changeset.
Use a common `ReliableTimeProvider` for test execution

- For external process, WorkerServices registry has a reliable TimeProvider

- For client side, use TimeProvider build process

  1. … 5 more files in changeset.
Use a common `ReliableTimeProvider` for tooling API `ConnectorServices`

  1. … 5 more files in changeset.
Revert "Change to getClass() from instanceof (#2117)"

This reverts commit 5df3e0126992270844f189793407bb016c18271c.

There was a major performance regression with this commit.

  1. … 2 more files in changeset.
Change to getClass() from instanceof (#2117)

* Change to getClass() from instanceof

This prevents our breaking the symmetrical property of euqals through

extension.

EqualsVerifier also noticed some minor problems with some of the

equals() implementations especially around their handling of null values.

I fixed the implementations to deal more gracefully with nulls, but

without changing the core concepts of what equals() meant for each

type.

  1. … 2 more files in changeset.
Favour `ClassPath.EMPTY` over `new DefaultClassPath()`

As it is more intent revealing, shorter and avoids an allocation.

  1. … 11 more files in changeset.
Settings script detection takes scripting language providers into account

  1. … 18 more files in changeset.
Renamed class.

  1. … 3 more files in changeset.
Ensure the correct TAPI progress events are generated when distribution download is cancelled. Moved responsibility for coordinating download and cancellation so that it happens inside the generation of start and finish events, rather than around it.

  1. … 5 more files in changeset.
Generate start and finish events for Gradle distribution download done by the TAPI.

Also moved responsibility for creating the downloader down closer to where the download happens, and inject only the listeners that are interested in the events.

  1. … 12 more files in changeset.
Allow running tasks before executing BuildAction

Introduce methods forTasks in tooling API's BuildActionExecuter so the

user is able to run tasks before having his BuildAction executed, in the

same connection.

This feature is useful in Android development for determining a list of

APK slipts (running some tasks) and return a model with them afterwards

so the IDE can configure the project.

  1. … 9 more files in changeset.
tooling: report gradle wrapper download progress

  1. … 63 more files in changeset.
DefaultToolingImplementationLoaderTest test fix unwrapping ParameterValidatingConsumerConnection

Revert "Move @TargetGradleVersion and GradleVersionSpec to central integ test infrastructure, from Tooling API test infrastructure."

This reverts commit e71f77c55e865f583ff930fc29fb9c33a089f33b.

  1. … 98 more files in changeset.
Move @TargetGradleVersion and GradleVersionSpec to central integ test infrastructure, from Tooling API test infrastructure.

This will be needed in upcoming TestKit tests.

+review REVIEW-6414

  1. … 98 more files in changeset.
Add project/build identifiers to all core models

This avoids the need for compatibility mapping on the client.

Having project and build information on all models is also a prerequisite

to make build actions in composite builds work. The build controller takes

a 'target' argument and from that argument we need to be able to infer which

build and project it belongs to.

  1. … 50 more files in changeset.
Apply all model mixins in build actions

Up until now many compatibilty mappings were only applied

when calling `ProjectConnection.getModel()`, but not when using

`BuildController.getModel()`. As a result, models retrieved by

a build action were less user friendly.

Both code paths now use the same compatibility mapping logic.

  1. … 26 more files in changeset.
Allow `!nnn` expression in `@ToolingApiVersion` to mark a test as broken for a particular version, but valid for all others.

  1. … 2 more files in changeset.
Remove GradleConnection API

The GradleConnection API was our first attempt at

implementing composite builds. We have improved on that

in Gradle 3.1, allowing the user to define composite builds

in settings.gradle and giving the user much more control

over how dependency substitution works.

A composite build is a normal Gradle build as far as the

Tooling API is concerned, so the separate concept of

the GradleConnection is no longer needed. We will add

methods for fetching all models from a composite build

to ProjectConnection in Gradle 3.2

  1. … 129 more files in changeset.
Fixed some hotspots when constructing and using tooling api models.

    • -0
    • +43
    ./org/gradle/tooling/internal/adapter/TypeInspectorTest.groovy
  1. … 2 more files in changeset.
Changed the tooling API to reuse views generated for tooling models created by a BuildAction.

  1. … 10 more files in changeset.
Fixed mixing in of identifiers for `GradleProject` and `BasicGradleProject` tooling models.

  1. … 9 more files in changeset.
Changed the tooling API to discard all cached views for a tooling model when the model is serialized. They are recreated as required when the deserialized model is traversed.

This change also allows parts of the tooling model to be serialized without dragging in the whole tooling model.

  1. … 1 more file in changeset.
Complete the transition to a declarative API for `ProtocolToModelAdapter`, by removing the `adapt(..., Action)` method and replacing usages of this with usages of `ViewBuilder<T>`.

  1. … 16 more files in changeset.
Changed `ProtocolToModelAdapter` to allow beans to be mixed into the views for objects of a given type. Removed the capability to attach an opaque `MethodInvoker` instance with a view.

Changed the mixing in of build and project ids into tooling models to use a bean instead of a `MethodInvoker`.

  1. … 3 more files in changeset.
Started to introduce a more declarative API to `ProtocolToModelAdapter` for tweaking how model views are constructed. This API will replace replace the opaque `Action`, to allow some optimisations in how the views are implemented and serialized.

  1. … 4 more files in changeset.
Fixed broken unit test.

Changed tooling API to attempt to reuse proxies generated for tooling model objects received by a client provided `BuildAction` and forwarded to the client.

  1. … 6 more files in changeset.
Fixes to tooling API to deal with an instance that forms part of a tooling model and which can be viewed as different types in different locations in the model.

  1. … 1 more file in changeset.
Changed tooling API to attempt to reuse a proxy generated for a given instance that forms part of a tooling model.

  1. … 3 more files in changeset.