Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Report TAPI progress events for project configuration

This commit introduces a new `OperationType.PROJECT_CONFIGURATION` and

adds specific `ProgressEvent` implementations. When the operation type

is not requested, no progress configuration events (neither as typed

events nor as generic build operations) will be reported. While that

will remove generic progress configuration events and their children

from clients that use old TAPI versions against Gradle >= 5.1, it is

consistent with the behavior for tasks and work items.

  1. … 40 more files in changeset.
Report task dependencies to TAPI listeners

The dependencies of a task are now reported as part of

`TaskOperationDescriptor`. If the information is not available due to

a pre-5.1 target version, an `UnsupportedMethodException` is thrown.

  1. … 10 more files in changeset.
Report TAPI progress events for work items

This commit introduces a new `OperationType.WORK_ITEM` and adds specific

`ProgressEvent` implementations. For backwards compatibility, if the

new OperationType is not requested, but `OperationType.GENERIC` is, it

will be reported as a generic build operation.

  1. … 38 more files in changeset.
Add some context to the exception thrown by the TAPI when the daemon is force killed on cancellation.

Remove some consumer side assumptions about the implementation of the producer, which were present as a work around to produce the correct exception in the consumer when the daemon is force killed by the producer and for very old producer versions.

  1. … 11 more files in changeset.
Remove dead code from the TAPI

  1. … 20 more files in changeset.
Remove support for connecting to Gradle <2.6

  1. … 134 more files in changeset.
Change the allocation of progress operation ids so that it is likely that the progress operation id and build operation id of a given start event are the same, and take advantage of this to avoid serializing the build operation id and parent build operation id when they are same as the corresponding progress operation id.

A later change could potentially merge these two separate ids and avoid the cost of tracking two separate, but almost always correlated, values.

  1. … 11 more files in changeset.
Remove public PhasedBuildActionExecutor type

The type behaves just like a regular build action

except that it can hook into different phases of

the build.

  1. … 15 more files in changeset.
Rename phasedAction() to action()

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

  1. … 3 more files in changeset.
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. … 17 more files in changeset.
Make phased actions run tasks only when defined

With this commit, in order to specify if a PhasedAction should run tasks

or just configure the build, the API forTasks is used: when tasks are

defined (or an empty collection is given), Gradle will run tasks,

otherwise only configure the build.

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

  1. … 7 more files in changeset.
Use umodifiable list in DefaultClassPath

This makes accidental mutation impossible and reduces some

of the repeated wrapping.

  1. … 34 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. … 32 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>

  1. … 48 more files in changeset.
Remove unused imports

Remove `ScriptingLanguage` SPI

`ScriptingLanguage` becomes a simple data class with hard-coded values in Gradle core.

Pros:

* much simpler code

* more correct behaviour: Kotlin scripts are found even when the JVM runtime wouldn't allow the provider to be loaded

* better runtime behaviour (possibly incompatible classes are not loaded until a Kotlin script is actually needed)

Cons:

* hard-coded class name in Gradle core

* no longer extensible

* file extension is under Gradle core control, not `kotlin-dsl`

  1. … 16 more files in changeset.
Improve error messages for ToolingParameterProxy

ToolingParameterProxy#isValid is replaced by #validateParameter which instead

of returning a boolean indicating if the given Class<?> is a valid parameter

type, it throws an error with a precise description message if not valid.

  1. … 2 more files in changeset.
Fix test expectation

Improve error messages in BuildControllerAdapter

  1. … 5 more files in changeset.
Simplify handling of versions not supporting parameters

  1. … 4 more files in changeset.
Pull ScriptFileResolver up in favor of BuildLayoutFactory

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

  1. … 30 more files in changeset.
Parameter connection related code simplification

Renamings and code simplifications suggested in the pull request.

No functionality changed.

  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.

  1. … 30 more files in changeset.
Code clean up for parameterized models

Refactorings and code clean up folloiwing commit "Introduce creation of

parameterized tooling models"

  1. … 21 more files in changeset.
Deprecate support for old TAPI providers (#2913)

Deprecation TAPI provider older than 2.6

https://github.com/gradle/gradle-private/issues/898

This change deprecates running Gradle older than 2.6 via Tooling API

  1. … 11 more files in changeset.
Strive to keep Gradle's monotonic clock in sync with the system clock

  1. … 71 more files in changeset.
Simplify time handling internally and for build scans (#2857)

* Don't make TimeProvider Serializable.

This isn't safe and generally doesn't make sense.

* Extract and promote the concept of a build timer.

This was previously not well defined and being overlaid with the concept of when a user/tool requested something, which is not always the same thing.

* Pare down the deprecated org.gradle.util.Clock down to the minimum required.

Internal usage is replaced by a `getStartTime()` directly on BuildRequestContext.

What is left is only kept for backwards compatibility with scans.

* Rename TimeProvider to Clock.

* Move BuildExecutionTimer out of baseServices into core, and into a better package.

* Remove unused.

* Simplify the time package by merging types.

* Prevent the client's build started timestamp from being later than when the provider received the build request.

* Provide a dedicated mechanism for conveying the build start time to build scans.

* Consolidate the ways of formatting durations.

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

  1. … 35 more files in changeset.