Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Remove projectsEvaluated hook from PhasedActions

And modify projectsLoaded hook to be run after configuration, making

sure that requested models are available.

For now, projects are configurated completely before running the

projectsLoaded action, however we can try to avoid unnecessary

configuration in the future without modifying public APIs.

Signed-off-by: Lucas Smaira <lsmaira@google.com>

  1. … 18 more files in changeset.
Change exception handling when phased action fails

Exceptions in BuildActions of a PhasedAction are now immediately thrown

and the build imediatelly fails. This makes sure that if an action fails

the remaining steps of the build will not uselessly be executed.

Exceptions are unwrapped in ProviderConnection so the correct

information is sent back to the TAPI client.

This commit also addresses other review comments in the PR:

- Removes unnecessary @since annotations in methods

- Adds a test (ignored for now) making sure that default tasks are not

run when no tasks are specified by the user

Signed-off-by: Lucas Smaira <lsmaira@google.com>

  1. … 8 more files in changeset.
Change target version from 4.7 to 4.8

Changing all uses of 4.7 in documentation and code.

Signed-off-by: Lucas Smaira <lsmaira@google.com>

  1. … 30 more files in changeset.
Code and documentation ajustments to PR

This commit:

- Renames methods in PhasedBuildActionExecuter and corresponding uses

- Improves public java docs making them more precise

- Replaces mocks by stubs in unit tests when possible

- Makes action's handlers in phased actions not receiving failures (they

are send to build results)

Signed-off-by: Lucas Smaira <lsmaira@google.com>

  1. … 34 more files in changeset.
Introduce support for running phased actions

This commit introduces the ability of running multiple build actions in

different phases of the build. These actions are passed by the client

through the tooling api.

With this commit, a single action can be added to each one of the

supporting phases (after projects are loaded, after projects are

evaluated and after tasks are run).

This feature allows improvements like running actions that call a model

builder modifying the graph tasks, and then it is possible to first

fetch a model and then execute tasks, in this order. e.g. Android Studio

sync + source generation.

Signed-off-by: Lucas Smaira <lsmaira@google.com>

    • -0
    • +28
    ./AfterBuildResult.java
    • -0
    • +28
    ./AfterConfigurationResult.java
    • -0
    • +28
    ./AfterLoadingResult.java
    • -0
    • +55
    ./InternalPhasedAction.java
    • -0
    • +61
    ./InternalPhasedActionConnection.java
    • -0
    • +51
    ./PhasedActionResult.java
    • -0
    • +34
    ./PhasedActionResultListener.java
  1. … 47 more files in changeset.
Change version of parameterized models to 4.4

This commit modifies all the java docs and concerned files in previous

commits in this pull request.

    • -6
    • +6
    ./InternalBuildControllerVersion2.java
    • -6
    • +6
    ./InternalParameterAcceptingConnection.java
  1. … 26 more files in changeset.
Parameter connection related code simplification

Renamings and code simplifications suggested in the pull request.

No functionality changed.

    • -11
    • +6
    ./InternalCancellableConnection.java
    • -78
    • +0
    ./InternalCancellableConnectionVersion2.java
    • -0
    • +56
    ./InternalParameterAcceptingConnection.java
  1. … 13 more files in changeset.
Change version of parameterized models to 4.3

This commit modifies all the java docs and concerned files in previous

commits.

    • -6
    • +6
    ./InternalBuildControllerVersion2.java
    • -9
    • +9
    ./InternalCancellableConnectionVersion2.java
  1. … 26 more files in changeset.
Code clean up for parameterized models

Refactorings and code clean up folloiwing commit "Introduce creation of

parameterized tooling models"

  1. … 26 more files in changeset.
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.

    • -0
    • +36
    ./InternalBuildActionVersion2.java
    • -0
    • +43
    ./InternalBuildControllerVersion2.java
    • -3
    • +13
    ./InternalCancellableConnection.java
    • -0
    • +78
    ./InternalCancellableConnectionVersion2.java
  1. … 32 more files in changeset.
Replace usages of org.gradle.api.Nullable

With javax.annotation.Nullable.

  1. … 460 more files in changeset.
Address more comments from review

+review REVIEW-6361

    • -28
    • +0
    ./events/InternalTaskCacheResult.java
    • -0
    • +26
    ./events/InternalTaskCachedResult.java
  1. … 6 more files in changeset.
Fix some more review comments from Ben and Lorant

+review REVIEW-6361

  1. … 5 more files in changeset.
Support querying for FROM_CACHE result through TAPI/TestKit

- For older versions of Gradle TAPI, this looks like an up-to-date result.

- For newer versions of Gradle TAPI, a new "isFromCache" property is available.

    • -0
    • +21
    ./events/InternalTaskCacheResult.java
  1. … 12 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. … 56 more files in changeset.
Remove traces of old composite build testing

  1. … 6 more files in changeset.
Remove IdeaModuleDependency#getTarget()

Instead, provide the target module name. The getTarget() method was

introduced with the use case of a client-managed composite in mind.

This use case is no longer supported, composites are managed by the

coordinating build.

  1. … 12 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

    • -45
    • +0
    ./InternalCompositeAwareConnection.java
  1. … 136 more files in changeset.
Removed `EclipseProjectIdentifier`

For the Eclipse model, we assume that the name of an EclipseProject is

sufficient for identification, and that the path of a ProjectDependency

is sufficient to locate the target project.

Based on that assumption, this commit removes the separate identifier

that was added to the eclipse model. It also simplifies the code for

wiring up dependencies in the Eclipse model, removing the need to track

the ProjectComponentIdentifier for each project dependency.

    • -48
    • +0
    ./eclipse/DefaultEclipseProjectIdentifier.java
  1. … 13 more files in changeset.
Stop tracking projectId for IDEA module dependency

For the IDEA model, we assume that the name of a IDEA module is

sufficient for identification. Based on that assumption, this commit

simplifies the code for wiring up dependencies in the IDEA model,

removing the need to track the ProjectComponentIdentifier and project

directory for each module dependency.

  1. … 6 more files in changeset.
Removed support for invoking Gradle versions older than 1.2 through tooling API. This is now an error.

  1. … 45 more files in changeset.
Javadocs.

Added some more test coverage for warnings generated when using a deprecated tooling api client version.

  1. … 3 more files in changeset.
Added integration test for Idea module dependencies (and fix)

  1. … 3 more files in changeset.
Added `IdeaModuleIdentifier` allowing idea module dependencies to be identified in a composite

- `IdeaModule.identifier` returns a unique identifier for the module

- `IdeaModuleDependency.target` returns the unique identifier for the target module

- Compatibility mapper sets these values for older gradle versions

    • -0
    • +52
    ./DefaultIdeaModuleIdentifier.java
  1. … 18 more files in changeset.
Use an opaque `EclipseProjectIdentifier` to correlate project dependencies

    • -0
    • +48
    ./eclipse/DefaultEclipseProjectIdentifier.java
  1. … 10 more files in changeset.
Revert "Removed a bunch of stuff related to the daemon composite coordinator for the 2.13 release"

This reverts commit 7616f0700c654d96bb9a36a6ecf13645d9083ff9.

    • -0
    • +45
    ./InternalCompositeAwareConnection.java
  1. … 12 more files in changeset.
Removed a bunch of stuff related to the daemon composite coordinator for the 2.13 release

    • -45
    • +0
    ./InternalCompositeAwareConnection.java
  1. … 12 more files in changeset.
Moved BuildIdentity and ProjectIdentity to better packages

- Interface types to `org.gradle.tooling.model`

- Implementation types to `org.gradle.tooling.internal.connection`

  1. … 31 more files in changeset.
Merged `GradleConnectionPartipant` into `GradleParticipantBuild`

  1. … 11 more files in changeset.